Re: resize image surface

Am 29.09.2012 19:58, schrieb chris nuernberger:
> I don't think that is a very good match really.
>
> I need the *results* of the drawing operation to be packed and
> contiguous in memory because as I stated upload to is sensitive to the
> total data size and the image data upload functions don't include a stride.

Just looked at your given code-example - and what I'm missing there
(and what would be a valid solution that keeps the performance
  at a good level, since it avoids the allocation of the image-
  buffer at least) is:

cairo_image_surface_create_for_data

This way you could allocate a single buffer large enough for all your 
expected Image-Sizes already on App-Startup - and then only use
the pointer to this global buffer within each and every surface-
creation-call (based on the just mentioned API-routine above).

This way you would (also for the smaller surfaces) avoid the
reallocation of an image-buffer - but then the drawback is,
that you would have to clear the content of each freshly
returned "Sub-Surface" before you start to draw anything.

Maybe this "necessity to clear up before drawing" is of no real
concern to you, which would be the case for example, when
each of your smaller subsurfaces renders its text onto different
"backgrounds" in either case (meaning that a "SrcBlit" is necessary
anyways, before rendering the Text).

If that is not so, and you always want to draw the Text on a clean
"zeroed out" Background, then you would have to compare the two
approaches performancewise.

cairo_image_surface_create (allocating new zeroed out memory)
+ usually accompanied by deallocation (destroying) of the old surface

vs.

cairo_image_surface_create_for_data (against a globally shared buffer)
+ zeroing out the background yourself (or per cairo-fill on the new surface)

I think the latter approach would be the faster one.

Olaf



-- 
cairo mailing list
[email protected]
http://lists.cairographics.org/mailman/listinfo/cairo