[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 Mon, 03 Apr 2006 20:52:45 -0400 Jason Tackaberry <tack@sault.org> babbled:

> 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

yup - i know :) i have handled this in emotion and it does it just fine (thank
god) thus dvd playback using emotion is a doodle :) xine does the heavy lifting
- emotion just plugs the right things in the right places. since for me the
video is just another object - it just is under all the OSD objects within the
canvas - its the reverse to what you do as the canvas is within the video stream
(so to speak). one day when x gets accelerated yuv blits (ie i can use xvideo
with a pixmap/xrender picutre) i can finally accelerate yuv->rgb :)

> 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.

yup - you can just re-alloc it on these "odd" occasions :)

> 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.

actually you dont need a new canvas - just get the engine info - change the
outbuf pointer, set the info back, the output w/h and viewport and it will work
with a live/existing canvas.

> 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.

yeah - lot of waste - try the above. it should work. :)

> 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? :)

it should be. see above. this is what i'd "expect" would be the normal case. :)

> Cheers,
> Jason.

------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster@rasterman.com
Tokyo, Japan (東京 日本)