Dear Matthew,
I know you were not commenting/criticizing and I'm not criticizing Clutter either :-) The bytes are not swizzled, they come in the correct order from Cairo already, the (uint32) (((a) << 24) | ((r) << 16) | ((g) << 8) | (b)) part was just to show how the channel data is arranged into memory. The dominant other types of data in my case are of luminance variety and any manipulations are done in the colormap which is applied with a fragment program. Clutter, on the other hand, has to support many other formats and has to deal with (un) premultiplied alpha... Just a suggestion, there are hints here and there on the web that the proper way to do blending is to use premultiplied alpha, maybe it's possible to write a fragment program to do the premultiplication for those sources of texture data? I'm sure that other issues would arise then though... I was evaluating using Clutter because of its very interesting ClutterTimeline and encapsulation of all that tedious GL setup code. Then I stumbled on the pangoft2 dependency and asked about any plans to change that. I agree that advancing carefully in the best interest of your users is the appropriate course of action and I wish you the best of luck. Have a nice weekend, Bogdan ---------------------------------------- > Subject: RE: [clutter] pangoft2 vs pangocairo > From: [EMAIL PROTECTED] > To: [EMAIL PROTECTED] > CC: [EMAIL PROTECTED]; [email protected] > Date: Sat, 26 Apr 2008 00:37:19 +0100 > > 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 > _________________________________________________________________ Discover the new Windows Vista http://search.msn.com/results.aspx?q=windows+vista&mkt=en-US&form=QBRE-- To unsubscribe send a mail to [EMAIL PROTECTED]
