[prev in list] [next in list] [prev in thread] [next in thread] 

List:       enlightenment-devel
Subject:    Re: [E-devel] Ewl_embed mysterious black border
From:       Carsten Haitzler (The Rasterman) <raster () rasterman ! com>
Date:       2005-05-31 22:28:22
Message-ID: 20050601072822.339051cf () icky
[Download RAW message or body]

On Fri, 27 May 2005 16:35:16 +0100 Simon Poole <simon.armlinux@themalago.net>
babbled:

> I would love to do that, but unfortunately on the platform I'm using
> (200MHz ARM-based EP9312) Evas is too slow to run full-screen.
> 
> With a 640x480 screen there is a noticeable swipe on each full-screen
> update.  With a 1280x1024 screen it is even worse.  Our app involves
> frequent full-screen updates, so that's kind of fatal.  I
> prerender/dither all images to 16bpp and do a hardware flip to put them
> on-screen.

hmm i see. interesting as i have really not observed these before - then again
the 200mhz arm box i have done evas stuff on is 320x240 so there is much less
screen to update :) i guess one problem is that it can only update at best at
bus write bandwidth. that is made worse by the fact it saves memory copies by
doing a convert from 32bpp to screen depth (likely 16bpp) while copying the
updates to the screen - it saves bandwidth and is an actual speedup, but it
exposes this step to you if it happens to be slow enough to notice such an
update.. in order to do such hardware flips i'd have to introduce full double
buffering concepts in evas (as evas inherently is single-buffered in that it
only maintains current and previous states. double buffering would mean we
maintain cur, prev and prev2). i'd need to add to the engines an api for the
engine to tell evas how many states to keep i guess. :)

> However, Evas is more than capable of animating smaller UI elements and
> I think it's immensely suitable for that job.

well it likely can do the whole job :) but just its fb output interface is a 
bit simple. i've never focused on it a lot. i always kind of thought if your
system is that limted that you can WATCH an update even with evas's code (which
is quite optimised in sheer ability to get pixels rendered to the screen of that
level of complexity) then maybe the hw needs some acceleration help :)

> I'm currently relying on the fact that when Evas repaints, it only ever
> touches tiles with Evas_Objects in (apart from blanking the whole screen
> when it is initially created).  Is that a reasonable assumption?  When

definitely not. for example the opengl engine actually does a bounding box
re-render... as gl SUCKS at handling updating lots of smaller update rects. gl
can invariably re-render a single rect or the whole screen faster than it can
render 5x 20x20 rects - as opposed to a single 1600x1200 rect region :) it's
definitely not something i'd rely on :) as i was saying above. i think the
solution would be to add infrastructure to handle another stored state, engines
saying how many states to use, virtualize the state pipeline/copy system (even
remove copy by just using a state ref table per object and just change the table
pointers to point to cur, prev and prev2, prev3 etc. states), then have the
engine render offscreen as it does currently and on a flush, do a hw flip. in
fact dont even wait to flip.. fork off a child that waits till vblank to flip
(unless the hw can flip screens without having to wait till vblank to do it -
and the flip only takes effect next screen scan). also make the same changes i
made to the x11 engine - to sync all rgba buf -> screen copies/updates to happen
at the same time so u dont see each region updating.. then again with double
buffering it wouldn't matter :) we need to work in single buffering as not
everything CAN double buffer... nor do u always want it :) but this is the
"correct solution" i would say - it would 1. give you a high quality RGBA output
engine so you don't ever have to care again what the output is - just feed it
32bit ARGB data and that's the last you care :) you know that whatever the
target display, it will do its best to get it there looking decent.

anyway - we could work together on this. IF you are willing to do this (it's up
to you). to save me a bit of researching - i could do with: 1. detect if fb
can/has double buffering ability code. 2. code to actually do the flip. 3. code
to know if the flip happens instantly or is deferred till the next frame update.
4. code to do a BLOCKING flip (or be able to query until vblank time to do flip
then), 5. code to know just where the backbuffer lives in video ram (and make
sure its mapped in as well as the front buffer). the rest is as described above.


> my app takes over, I hide all Evas objects before accessing the
> framebuffer directly.  Then when I show the Evas objects again, I expect
> to still see my own stuff around the outside.
> 
> I'm happy to tweak the dialogs to 8-pixel boundaries!

beware - that isn't a guaranteed. it used to be 16x16 pixel tiles. i found 8x8
just as easy on the cpu but a bit more accurate in limiting overdraw :) but ii
guess this is the fastest solution... BUT its not guaranteed to always keep
working... :) beware when i get the "lets play with the fb engine" bug... 


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


-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[prev in list] [next in list] [prev in thread] [next in thread]