On Mon, 03 Apr 2006 20:52:45 -0400 Jason Tackaberry <[EMAIL PROTECTED]> 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) [EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
