Hi; On Sat, 2008-04-26 at 01:02 +0200, Bogdan Nicula wrote: > > Sorry for replying to myself. > > >>> On the GL side, something like: > >>> glTexImage2D(GL_TEXTURE_RECTANGLE_ARB, 0, GL_RGBA, w, h, 0, > >>> GL_BGRA, GL_UNSIGNED_INT_8_8_8_8_REV, > >>> data); > > The justification for the above comes from Apple documentation: > > http://developer.apple.com/documentation/GraphicsImaging/Conceptual/OpenGL-MacProgGuide/opengl_performance/chapter_13_section_2.html#//apple_ref/doc/uid/TP40001987-CH213-SW23 > > section "Use Optimal Data Types and Formats" which I will cite in entirety in > its present form: > > " > If you don't use data types and formats that are native to the graphics > processor, you'll incur a costly data conversion. > > For vertex data, use GLfloat, GLshort, or GLubyte data types. Most graphics > processors handle these types natively. > > For texture data, you’ll get the best performance, regardless of > architecture, if you use the following format and data type combination: > > GL_BGRA, GL_UNSIGNED_INT_8_8_8_8_REV > > These format and data type combinations also provide acceptable performance: > > GL_BGRA, GL_UNSIGNED_SHORT_1_5_5_5_REV > GL_YCBCR_422_APPLE, GL_UNSIGNED_SHORT_8_8_REV_APPLE > > The combination GL_RGBA and GL_UNSIGNED_BYTE needs to be swizzled by many > cards when the data is loaded, so it's not recommended. > " >
But weren't you swizzing the bits in software before pushing to the texture anyway from your original example ? And I made no comment/criticism on the gl type/format you were using (Clutter uses various). > >> > >> Ok, but you are not un premultiplying the alpha (which afaik is always > >> used with the cairo image surface - see source of clutter-cairo). All > >> though it looks ok on the surface it will likely have issues in certain > >> situations. I have never found a GL pixel format that uses pre mulled > >> alpha. > > > > I'm not sure that it addresses the issue, but I'm using for the OVER > > operator (which is the only one I was interested in): > > glBlendFunc(GL_ONE, GL_ONE_MINUS_SRC_ALPHA); > > Others agree that the correct way to do blending of textures with GL is use > premultiplied textures and the above blending function, see, e.g. > http://lists.trolltech.com/qt-interest/2006-08/thread00039-0.html > Yeah I know that but then you end up having to convert all loaded image data etc to also be pre mulled before also loading into a texture ? IIRC Im sure I tried this route early on in Clutter and hit other issues too. The eventual aim to run Cairo on top of openVG in Clutter ie not using the imaging backend - then these pre mul issues should go away (and pangocairo potentially gets very interesting). Anyway my point was kind of to just mention some of the things the current renderer does just to show a change to pangocairo is not completely strait forward and has some risks. With the glyph texture caching however slow we blit the glyphs into that may not make alot of of difference to actual rendering performance overall. It is important however to save texture memory. Have a good weekend; == Matthew -- To unsubscribe send a mail to [EMAIL PROTECTED]
