On Sun, 29 Feb 2004 05:22:05 +0100 Hallvar Helleseth <[EMAIL PROTECTED]>
babbled:
> On Sun, 2004-02-29 at 04:15, Carsten Haitzler wrote:
> > On Sun, 29 Feb 2004 00:03:37 +0100 Hallvar Helleseth <[EMAIL PROTECTED]>
> > babbled:
> >
> > > Hi!
> > >
> > > In my attempts to make edje work on DirectFB I did what Ive been
> > > waiting a long time for: use Edje to get some sweeet looking bootup
> > > graphics 2 seconds after linux boots up (yes, that's actually 2 seconds!).
> > >
> > > I'm hoping this will spark some interest in getting involved with
> > > improving DirectFB - Evas/Ecore/Edje compatability/bindings.
> >
> > I'm all for that. so far we have X & FB support working ok. The FB support
> > is not the best since its mouse and keyboard driving is very simplistic -
> > but it does work.
> Great! Don't know if you're going to like the quality of my code in
> Ecore and Evas though! hehe.. Ive been promising a patch for a long
> time.. haven't really touched much for a few months, until today.
ok - well 2 comments before you send a patch.
1. keep indentation and style the same. it's nicer to have it all 1 style.
2. keep naming (function, parameter, variable etc.) conventions similar
3. check your code builds and doesnt break other parts of ecore, etc.
> DFB has good input support for many devices
> (http://tolva.shacknet.nu/modules.php) and they are all modules.
> > DFB is a good target. NB: the DFB rendering routines in Evas could
> > definitely be optimised - especially the Text routines. :)
>
> Two major bugs: (I have no clue how to solve them, Ive tried everything
> my skills allow me to)
>
> 1. Wierd stuff happends with text when not using --dfb:no-hardware... I have
> NO idea whats going on.. tested on Matrox G550 and radeon 9600XT.
i wouldnt know either! :) again - evas's dfb enging could do with some work :)
i might guess the text is suffering from pixel alignment problems to do with
assumed byte/row alignment etc. b ut again - not sure.
> 2. and the other is the alphablending which you pointed out a long time
> ago. I believe when using Matrox G550 the alphablending is okey. Im
> having a hard time figuring out who to blame for it... DirectFB or Evas?
> or both?
evas's alpha blending is fine. dfb's destination alpha code has bugs. i cangt
actually remember the details anymore - but i defnitnely narrowed it down to
fb either simply not implimenting a feature at all, or implimenting it
incorrectly.
> Im putting up a screenshot showing both bugs:
> http://tolva.shacknet.nu/screenshots.php?id=21
>
> > BTW - your app will probably run significantly faster with evas's FB driver
> > and ecore's FB support. :)
> I don't think so when the DirectFB radeon driver is complete! Matrox
> G550 is also by far faster than fb and X, beats them by a whole lot!
aaah! but it ISNT complete! :) that's the thing - and what about all the
other cards with only half dont or no drivers? evaqs fb will be significantly
faster and better quality in those situations.
personalyl i think this shoudl be the job eventually of ecore_evas -
selecting the best engine for the job (fb, dfb, x etc.) based on 1. what's
available and 2. speed. there should be a speed texting suite to determine
which to use (and maybe a speed vs. quality tester) and then it should make a
recommendation to a user "select engine X" and give performance and quality
numbers.
> > also rendering quality will be much higher than DFB. also
> > the advantage will be that you wont need DFb either so the initrd will be
> > smaller :)
> without directfb the initrd will be 308kb (libdirectfb) + 116kb (dfb
> modules) = 424kb lighter... which can be shaved even more with some
> special compile-time options. and the modules include jpeg and png
> imageproviders that aren't really necessary as evas does its own thing..
thats fairly light - still a bit lighter :)
> > but yes - the important thing is that the same app with (almost) no changes
> > will run on dfb, x (x software and gl - maybe xrender one day when xrender
> > stops being about 30 times slower than software rendering), fb and in future
> > other target displays.
> Evas/Ecore/Edje make up for one hell of a team! cheers!
they aren't complete and for now they arent a competitor to gtk, qt and some
things - but theres potential. :)
> I'm including patches for what Ive done so far.. its not meant for being
> imported into official cvs archives but If someone with more time wants
> to help out it would be really very nice! hopefully it will compile
> without major complications.. I think alot of stuff needs to be
> rewritten, I been mostly interested in getting it to work.
>
> hmm.. tried this but it doesn't include new files.. how can I do that?
> cvs diff -bBNau . > ../ecore-dfb.patch
>
> need to sleep! sending patch tomorrow :)
generate the patch then just attach new files. gthaqt should do for now. :)
again - maybe clean up the code first?
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) [EMAIL PROTECTED]
熊耳 - 車君 (数田) [EMAIL PROTECTED]
Tokyo, Japan (東京 日本)
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
enlightenment-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/enlightenment-users
