[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [E-devel] Bug with ARGB32 buffer canvas when stride != output width * 4

On Tue, 2006-04-04 at 08:47 +0900, Carsten Haitzler wrote:
> thus a copy to the final display device anyway. in your case i'm not sure why
> you need a larger rowstride anyway?

I'm not sure either.  When I discovered the bug last night I asked
myself the same question, and just changed all the code to set
stride=width*4 with no negative consequences.

What I'm doing is a kludge, really, and I knew it when I first coded it.
In xine, your frame size can change dynamically (consider a DVD changing
titles from fullscreen to anamorphic widescreen).  The OSD must need to
be able to change sizes dynamically, hence the canvas must be able to
change dimensions.  It can do this no problem, so long as the memory
buffer is big enough to hold the new dimensions.

So I allocated a "worst case scenario" buffer of 2000x2000 pixels, at
least as a stopgap until I decided what the correct way to do this was.
As long as my buffer was big enough to hold the canvas, I could just
change the output/viewport sizes without needing to allocate a new
buffer (and hence a new canvas).  I guess it just seemed intuitive for
me at the time that my rowstride is fixed at 2000*4, regardless of my
output size.

But of course the stride doesn't matter, so long as width*height*4 <=
2000*2000*4.  In fact stride=width*4 is better anyway, because this way
as long as that inequality is satisfied, it's possible for one of the
dimensions to exceed 2000.  (Not that that's likely to happen ever.)
But 2000x2000 is kludgy and arbitrary and a waste of memory.

The ideal solution would be to allocate a new buffer that's the
appropriate size and tell evas to use the new buffer without having to
allocate a new canvas and recreate all the objects on it.  Is this
possible now?  If not, could it be? :)