TextureMapper debug visuals-related functions should reuse textures whenever possible, specially when drawing FPS values on-screen (handled in bug 107942).
I've started thinking about a nice approach for this and came with two different ideas: 1. Add a RefPtr<BitmapTextureGL> m_fpsTexture to TextureMapperGL which would be updated if the repaint/frame count changes (also including additional info like color, position and transformation matrix). A separate drawFPS() function would be then necessary to differentiate from the repaint count texture. 2. FPS counter could be handled on its own compositing layer, so it could could paint itself into a separate backing surface to avoid unnecessary repaints. The latter solution sounds less hacky, however might add an unnecessary footprint. The former is easier to implement, but requires an additional BitmapTexture that shall live outside of BitmapTexturePool's scope. What do you guys think?
(In reply to comment #1) > I've started thinking about a nice approach for this and came with two different ideas: > > 1. Add a RefPtr<BitmapTextureGL> m_fpsTexture to TextureMapperGL which would be updated if the repaint/frame count changes (also including additional info like color, position and transformation matrix). A separate drawFPS() function would be then necessary to differentiate from the repaint count texture. > > 2. FPS counter could be handled on its own compositing layer, so it could could paint itself into a separate backing surface to avoid unnecessary repaints. > > The latter solution sounds less hacky, however might add an unnecessary footprint. The former is easier to implement, but requires an additional BitmapTexture that shall live outside of BitmapTexturePool's scope. What do you guys think? Both idea are good, but I have another idea. First of all, I'm not sure if we need to optimize drawBorder, which is already fast. When it comes to drawRepaintCounter (FYI, I tried to rename it to draw Number in Bug 109540), how about using texture atlas (refer to http://code.google.com/p/freetype-gl/). we need to draw only 1,2,3,4,5,6,7,8,9. So if we pre-build number texture, we can draw number quickly for both: repaint count and fps. What do you guys think?
(In reply to comment #2) > (In reply to comment #1) > Both idea are good, but I have another idea. > > First of all, I'm not sure if we need to optimize drawBorder, which is already fast. > > When it comes to drawRepaintCounter (FYI, I tried to rename it to draw Number in Bug 109540), how about using texture atlas (refer to http://code.google.com/p/freetype-gl/). > we need to draw only 1,2,3,4,5,6,7,8,9. So if we pre-build number texture, we can draw number quickly for both: repaint count and fps. > > What do you guys think? Sounds good, better than saving textures each time the value changes. Would clipping the border/number bounding box area out of the render layer tree (i.e. make it an opaque layer in front of all other RenderLayers, so they wouldn't need to render anything below this) also help?
Created attachment 188248 [details] Exploratory patch (TextureMapper::createNumberAtlas) This patch creates a number atlas GL texture using BitmapTextureGL. Do you guys agree on this approach?
(In reply to comment #4) > Created an attachment (id=188248) [details] > Exploratory patch (TextureMapper::createNumberAtlas) > > This patch creates a number atlas GL texture using BitmapTextureGL. Do you guys agree on this approach? good progress! you absolutely create number texture but it is not number texture atlas, because we can not get rect of each number on texture unit. you need to draw each number using TextRun and store the geometry info using your own data structure. See GraphicsContext::drawBidiText to know TextRun.