On Dec 17, 2007 6:13 AM, mario <[EMAIL PROTECTED]> wrote: > On Dec 16, 2007 11:04 PM, Gustavo Sverzut Barbieri <[EMAIL PROTECTED]> wrote: > > > I'm still working on my arm board: > > > All it's ok evas_fb_test run perfectly. > > > > > > Now I'm working on edje: there is a problem in a simple program: > > > > > Mario, it works great on Nokia devices (arm1136jf-s and arm926ej-s), I > > never tried with fb engine, just software_16_x11 and software_x11, but > > I can't see how can this change things. > > Solved. > I used an old (August) version of edje taken from > http://download.enlightenment.org/snapshots/ > Now I'm using the code from cvs and all it's ok.... > > ok but slow :( > better than qtopia but still slow! > next step: try the software16 engine over kdrive to see if something is > better. > ... even if kdrive seems to be impossibile to compile.
Please, try to write a fb_16 using software_16 as base. I can give you some hints, but if you know the fb you are working with, just try to write a dummy engine that does some output, then put software_16 as the base, look at software_16_x11, the general idea is: - create engine info - implement drawing functions to be the software_16 - implement output_redraws_next_update_get() [possible almost the same!] to get surface that primitives will draw to. See below. - implement output_redraws_next_update_push(): Mark somewhere regions that were dirtied, or send them to display. See below. - implement output_flush(): If it's cheaper to send all updates in one go, send marked regions here. Free resources reserved to draw this frame. General idea is quite simple, and to easy your implementation, get an older software_16_x11 that doesn't provide rotation, you can add it later. Remember that Evas render each frame, so output_flush() will be called after each frame. If you want to save allocation-free every time, you can 1) not free at all or 2) use output_idle_flush() that is called after some time no render is done (ie: animation ended). Also remember that we were dealing with X11, that involves 2 processes and IPC, then it's cheaper to use shared memory and just mark clip regions in an array, then inform which regions are dirty in one IPC call... possible it's the way to go with FB too, since you'll do syscalls in the end. > p.s. > for those who will came: pkg-config fails on cross-compiling: > sometimes you need to manually enable|disable what you want|dont in > the configure.in using what? I just noticed this using scratchbox and running pkg-config from inside python, i get some "interrupted system calls", but I think it's more an python-scratchbox issue than something else. -- Gustavo Sverzut Barbieri -------------------------------------- Jabber: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
