I have a situation where I am rendering text using pango to cairo surfaces and uploading them to openGL as textures.  <div><br></div><div>I render lots of small, usually one line but dynamically changing pieces of text.  </div>
<div><br></div><div>I am going to attempt to add an image resize function so I can resize an image context efficiently so that it will only allocate new memory if the original data capacity of the image context is insufficient to hold width * stride * height.  I would like to resize in the average case without any calls to malloc or free.</div>
<div><br></div><div>I was wondering if there was a way to force cairo to treat a surface as if it had a smaller width than it was originally allocated with instead when cairo is rendering?  This would solve the problem.</div>
<div><br></div><div>I need to take the surface post rendering and upload the surface data to openGL; uploading data, especially texture data to opengl is pretty sensitive to the size of the data.  Other options would include manually copying the subrect into a smaller image or something like that but this isn't as ideal as simple setting the image rect to be appropriately sized before rendering.  </div>
<div><br></div><div>Since there is no image_surface_resize function there seem to be two options.  First would be to write one which is the most straightforward way to a naive user like myself.  Second would be to somehow tell cairo that this surface is really less wide than it may seem at first glance.  Any other option seems to require either another memcpy post render somewhere or allocating memory for every text object every frame.</div>
<div><br></div><div>I am moving forward with attempting to resize the image surface, I would like to at least know what possible gotchas there are and how I could ensure they don't happen.  One possible gotcha I found after looking at the image surface struct was the cairo_damage could now have regions that are outside the dimensions of the image.  This won't cause crashing but it might cause invalid rendering.  Are there any other failures I should be aware of?  Any interactions with pango that might make this pathway infeasable?  I can always recreate the pango layer although I think that is kind of silly and most likely unnecessary.</div>
<div><br></div><div>Another perhaps more conservative path forward would be to drill down into every possible malloc and free that occurs during image surface creation and replace those with possibly user-overloaded functions and then ensure on the client side that I overload those functions to hit a special memory pool.  This, combined with the image surface creation system that takes a pre-allocated piece of memory would eliminate at least the memory traffic during rendering although it still does seemingly more work than it needs to.  It may be the only real safe way to resize the image surface depending on how much context cairo stores on the image surface and how difficult it is to clear this context.</div>
<div><br></div><div>Any help would be appreciated.</div><div><br></div><div>Chris<br clear="all"><div><br></div>-- <br>A foolish consistency is the hobgoblin of little minds - Emerson<br>
</div>