[cairo] resize image surface

[chris nuernberger]

Ah yes, I see your point.  You would think that growing up speaking English
I would communicate better in English...

Anyway, everything appears to work now.  For whatever reason, if I allocate
an alpha surface then I have to do a memZero(surface_data,
num_surface_bytes) after resizing the image because asking cairo to fill a
rect with 0,0,0,0 gets no result.

But the resize function +rendering works for alpha8 iimages and I think it
is minimal for my overall use case in that I don't allocate new memory
unless I really need to but continue to use the same block of memory as
much as possible, and I keep the texture upload sizes as small as possible.

I would love it if someone could look at the resize function attached to
the earlier and tell me under what conditions it will fail.  Keep in mind
that in my case all of my images are of sizes that are divisible by four so
that keeps pixman happy (row byte stride for pixman needs to be divisible
by four).  I imagine the code is far too reckless to be patched into cairo
itself so I won't hope for that.

Chris

On Sat, Sep 29, 2012 at 2:58 PM, Kalle Vahlman <kalle.vahlman at gmail.com>wrote:

> 2012/9/29 chris nuernberger <cnuernber at gmail.com>:
> > I don't think that is a very good match really.
>
> It matches "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" in my opinion...
>
> > 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.
>
> ...but not being contiguous is of course a problem if you can't
> specify the stride for the upload.
>
> --
> Kalle Vahlman, zuh at iki.fi
> Powered by http://movial.com
> Interesting stuff at http://sandbox.movial.com
>



-- 
A foolish consistency is the hobgoblin of little minds - Emerson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cairographics.org/archives/cairo/attachments/20120929/f321a527/attachment.html>