Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » Developing U++ » U++ Developers corner » About Painter vs OpenGL
Re: About Painter vs OpenGL [message #31497 is a reply to message #31494] Sun, 06 March 2011 22:57 Go to previous messageGo to previous message
mirek is currently offline  mirek
Messages: 14267
Registered: November 2005
Ultimate Member
Tom1 wrote on Sun, 06 March 2011 16:10

Well, this is certainly one of my favourite subjects, although I certainly do not know OpenGL nearly enough to say what can and can't be done.

Anyway, my point is that when comparing Painter and Draw simply as graphics programming interfaces, Painter provides a rich set of graphics primitives not available with Draw. Therefore, getting hardware acceleration available behind the Painter interface would definitely serve a purpose.

When I last checked, Painter defined three user selectable levels of rendering quality: No antialiasing, normal antialiasing and subpixel antialiasing. Whereas I gather from Mirek's notes that subpixel accurate



Please, there is some terminology issue about this. There are 2 different things:

- subpixel accuracy. That basically means that all coordinates are floating point and renderer does something about "fractional" numbers. In Painter, each pixel has 256 fractions. When rendering, if there is some part of polygon fractionally in the pixel, it affects it by that fractional value (and you get precise antialiasing that was).

- subpixel rendering. That, instead of taking screen pixel as 'whole', takes into account all 3 channels, which results in improved horizontal resolution.

Quote:


Would it be possible to implement a hardware accelerated 'SystemPainter' or 'OpenGLPainter' without subpixel antialiasing?



I believe not. You perhaps could imitate it to some degree, but OpenGL polygons are not compatible.

I Painter like system, "path" rules everyting.

I have seen some code in Qt that tries to do this, but I have seen that they have ended in quite complicated maths breaking "pdf" polygons into something that OpenGL is able to render.

That said - if you require fast graphics which is OpenGL able to provide, why not to use OpenGL directly?

Mirek
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: Executable as DLL
Next Topic: Google Summer of Code
Goto Forum:
  


Current Time: Sun Aug 24 08:14:55 CEST 2025

Total time taken to generate the page: 0.04333 seconds