On Fri, 31 Oct 2003 04:49:50 +0100 Hallvar Helleseth <[EMAIL PROTECTED]>
babbled:
> On Fri, 2003-10-31 at 04:19, Carsten Haitzler wrote:
> > > > aaah yeah. dfb's loaders... yup yup. forgot.. :) for now i'd just let
> > > > evas do the loading and just dump the pixel data to a dfb surface :)
> > >
> > > Maybe its a good idea to load all images with evas not using the
> > > DFBImageProviders..?
> >
> > probably. especially since in he future i will add more loaders & add
> > modular loader thingy :)
>
> Ok Ill fix that then :)
:)
> > > > hmm yup. works. definitely. but its synchronous lock-step. dont think i
> > > > like that. heres' what i'd do. i would have the "event" thread wait for
> > > > the next event and when it happens read the event info and write a data
> > > > struct down the socket to the main thread and then have the main thread
> > > > read the data form the socket and use that. now you get pipelining and
> > > > buffering and no need to lock-step back and forth PER event. :) that'd
> > > > be the way imho to do it :)
> > > Ill leave it for now, actually I think it works the way you want, but
> > > not sure. You can take a look if you want when I finish the patches.
> >
> >
> > yeah - but it does mean lock-step :( and thats awful for performance and
> > idle-time rendering etc. :(
>
> Not that I really know what lock-step is, but _ecore_dfb_fd_handler
lock step:
process(thread)1 = p1
process(thread)2 = p2
p1: p2:
p1 get event
p1 send to p2
p1 wait... p2 get data.
p1 wait... p2 reply to p1
p1 get reply
p1 get event
p1 send to p2
p1 wait... p2 get data
etc.
so p1 is not going to get a string of events at once and sent them all over
buffered within a single context switch. its going to keep switching back and
forth. is nicer on the cpu, os and scheduler if u dont do this
ie
p1 get event, put in buffer
p1 get event, put in buffer
p1 get event, put in buffer
p1 send 3 events to p2 p2 get event1
p1 wait for more events p2 get event2
p1 get event, put in buffer p2 get event3
p1 get event, put in buffer p2 get event4
p1 wait for events... p2 get event5
see p1 never waits for p2. it only waits for events then just punches them down
a pipe. :) its very efficient :)
> doesnt block or lock anywhere, and is similar to _ecore_x_fd_handler
> (with recv() before while and send() after, "nonblocking mode") only the
> event thread blocks on send())
>
> anyways, performance so far is about 4x better than software x11 ("edje
> e_logo.eet"), not accurate benchmarking ;) everything acts and performs
> smoothly on AMD Athlon 1.133Mhz
with hardware accel i assume? notice too that dfb wont do smooth scaling. its
all sampled only (scaling down) :)
> Patch is coming ASAP :)
>
> Hallvar Helleseth
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive? Does it
> help you create better code? SHARE THE LOVE, and help us help
> YOU! Click Here: http://sourceforge.net/donate/
> _______________________________________________
> enlightenment-devel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
The Rasterman (Carsten Haitzler) [EMAIL PROTECTED]
熊耳 - 車君 [EMAIL PROTECTED]
Mobile Phone: +61 (0)413 451 899 Home Phone: 02 9698 8615
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
_______________________________________________
enlightenment-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
