From: Jorge L. Z. M. <jor...@gm...> - 2007-07-18 22:20:20
|
Hi all, i have taken evas to be my guinea pig here =) I've split the common engine code into a different library, because with time it has became a really good direct rendering library. what would it benefit us? i have the idea that abstracting at the canvas level and at the rendering level would make objects to render themselves, and get away from engine level several non needed stuff because there's maybe no engine that can do what evas do internally. the latter isnt fully decided yet, but isolating concepts on the library is a good thing imho, you can do more benchmarks and have more control on what every part of the library does. So the first step im doing is to abstract the direct rendering code, if anyone is interested on this, reply :) |
From: Gustavo S. B. <bar...@gm...> - 2007-07-19 01:01:20
|
On 7/18/07, Jorge Luis Zapata Muga <jor...@gm...> wrote: > Hi all, i have taken evas to be my guinea pig here =) > > I've split the common engine code into a different library, because > with time it has became a really good direct rendering library. what > would it benefit us? i have the idea that abstracting at the canvas > level and at the rendering level would make objects to render > themselves, and get away from engine level several non needed stuff > because there's maybe no engine that can do what evas do internally. > the latter isnt fully decided yet, but isolating concepts on the > library is a good thing imho, you can do more benchmarks and have more > control on what every part of the library does. So the first step im > doing is to abstract the direct rendering code, if anyone is > interested on this, reply :) Ok, I already talked to you on IRC about this, just to make it available to ML: - Sanity checks and clip splitting should be done by core and engines should get the "ready" values. For example, no need to check for coordinates outside of the screen or rectangles of null area. Maybe call engine to process the final area, maybe a list of areas (in case some engine can handle this internally, like given the list of areas to be blended). Right now we have this replicated all over the place, I had to copy pieces of "common" in order to create "software_16". Collateral benefit is avoiding calling bunch of functions (non-local) to do nothing but return. - CPU-dependent features should be set to a inner, externally changeable structure. Instead of calling evas_common_cpu_* every time to get the correct function, we should get the structure from engines with these functions. This way I could have my own methods to draw rectangles in software_16 instead of implementing my own code that just differ on scanline processing. and I'd do this cleanup/refactor in this order, with small patches that we could review and apply, first without changing behavior, then more intrusive changes. We reduce number of bugs and get more feedback. Also on IRC we were discussing about usage of GIT for people at enlightenment.org, Jorge could get his work as a tree there, making it easy for people to use and later merge back. As we already have ssh keys for developers, it should be a matter of someone setup a script to scan for ~/public_git/ and list those on gitweb. We have something like this internally at INdT, but it's based on public scripts, so I can set it up. -- Gustavo Sverzut Barbieri -------------------------------------- Jabber: bar...@gm... MSN: bar...@gm... ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 |
From: Carsten H. (T. R. <ra...@ra...> - 2007-07-21 05:06:49
|
On Thu, 19 Jul 2007 00:20:16 +0200 "Jorge Luis Zapata Muga" <jor...@gm...> babbled: > Hi all, i have taken evas to be my guinea pig here =) > > I've split the common engine code into a different library, because > with time it has became a really good direct rendering library. what > would it benefit us? i have the idea that abstracting at the canvas > level and at the rendering level would make objects to render > themselves, and get away from engine level several non needed stuff > because there's maybe no engine that can do what evas do internally. > the latter isnt fully decided yet, but isolating concepts on the > library is a good thing imho, you can do more benchmarks and have more > control on what every part of the library does. So the first step im > doing is to abstract the direct rendering code, if anyone is > interested on this, reply :) I think this is a good idea. I have nothing against it - but we need to be aware that it makes breaking internal rendering api's harder :( i do agree that this will make benchmarks and testing of just raw routines much much much easier. for now i think this extra lib can just ship with evas - we can split it out later as/when needed. for now a big sign of "this api is going to break - don't use it in your app unless you like api's always breaking" on it. :) > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > enlightenment-devel mailing list > enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ra...@ra... 裸好多 Tokyo, Japan (東京 日本) |
From: Vincent T. <vt...@un...> - 2007-07-25 06:18:04
|
On Sat, 21 Jul 2007, Carsten Haitzler (The Rasterman) wrote: > On Thu, 19 Jul 2007 00:20:16 +0200 "Jorge Luis Zapata Muga" > <jor...@gm...> babbled: > >> Hi all, i have taken evas to be my guinea pig here =) >> >> I've split the common engine code into a different library, because >> with time it has became a really good direct rendering library. what >> would it benefit us? i have the idea that abstracting at the canvas >> level and at the rendering level would make objects to render >> themselves, and get away from engine level several non needed stuff >> because there's maybe no engine that can do what evas do internally. >> the latter isnt fully decided yet, but isolating concepts on the >> library is a good thing imho, you can do more benchmarks and have more >> control on what every part of the library does. So the first step im >> doing is to abstract the direct rendering code, if anyone is >> interested on this, reply :) > > I think this is a good idea. I have nothing against it - but we need to be > aware that it makes breaking internal rendering api's harder :( i do agree that > this will make benchmarks and testing of just raw routines much much much > easier. for now i think this extra lib can just ship with evas - we can split > it out later as/when needed. for now a big sign of "this api is going to break > - don't use it in your app unless you like api's always breaking" on it. :) again, a branch in cvs can be a good idea to test that. Vincent |
From: Carsten H. (T. R. <ra...@ra...> - 2007-07-25 11:49:46
|
On Wed, 25 Jul 2007 08:17:55 +0200 (CEST) Vincent Torri <vt...@un...> babbled: > > > On Sat, 21 Jul 2007, Carsten Haitzler (The Rasterman) wrote: > > > On Thu, 19 Jul 2007 00:20:16 +0200 "Jorge Luis Zapata Muga" > > <jor...@gm...> babbled: > > > >> Hi all, i have taken evas to be my guinea pig here =) > >> > >> I've split the common engine code into a different library, because > >> with time it has became a really good direct rendering library. what > >> would it benefit us? i have the idea that abstracting at the canvas > >> level and at the rendering level would make objects to render > >> themselves, and get away from engine level several non needed stuff > >> because there's maybe no engine that can do what evas do internally. > >> the latter isnt fully decided yet, but isolating concepts on the > >> library is a good thing imho, you can do more benchmarks and have more > >> control on what every part of the library does. So the first step im > >> doing is to abstract the direct rendering code, if anyone is > >> interested on this, reply :) > > > > I think this is a good idea. I have nothing against it - but we need to be > > aware that it makes breaking internal rendering api's harder :( i do agree > > that this will make benchmarks and testing of just raw routines much much > > much easier. for now i think this extra lib can just ship with evas - we > > can split it out later as/when needed. for now a big sign of "this api is > > going to break > > - don't use it in your app unless you like api's always breaking" on it. :) > > again, a branch in cvs can be a good idea to test that. be careful - then you need to deal with merging the branch - the existing software enigne code wont stay still forever. > Vincent > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > enlightenment-devel mailing list > enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ra...@ra... 裸好多 Tokyo, Japan (東京 日本) |
From: Vincent T. <vt...@un...> - 2007-07-25 14:01:11
|
On Wed, 25 Jul 2007, Carsten Haitzler (The Rasterman) wrote: > > be careful - then you need to deal with merging the branch - the existing > software enigne code wont stay still forever. before talking about merging, maybe it's time to write some code. There has been several times, by mails, discussions about internal changes and absolutely no code at all is available for other devs. so, if you're reluctant to merge with cvs, we have 2 solutions: 1) continuing the discussion by mail, hence no code will be available. It's a wonderful way to do development. 2) moving from cvs to another vcs, which allows merging easier than with cvs. Vincent |
From: Carsten H. (T. R. <ra...@ra...> - 2007-07-25 14:27:01
|
On Wed, 25 Jul 2007 16:01:05 +0200 (CEST) Vincent Torri <vt...@un...> babbled: > > > On Wed, 25 Jul 2007, Carsten Haitzler (The Rasterman) wrote: > > > > be careful - then you need to deal with merging the branch - the existing > > software enigne code wont stay still forever. > > before talking about merging, maybe it's time to write some code. There > has been several times, by mails, discussions about internal changes and > absolutely no code at all is available for other devs. > > so, if you're reluctant to merge with cvs, we have 2 solutions: > > 1) continuing the discussion by mail, hence no code will be available. > It's a wonderful way to do development. > 2) moving from cvs to another vcs, which allows merging easier than with > cvs. nothing to do with cvs that makes merging hard - if the same src is changed in 2 places - you get a conflict. humans need to resolve them. what we should do to start is JUST split off src/lib/engines/common - it already produces a .a file that is linked INTO libevas.so - ALL you need to do for now is produce a .so instead and link runtime as a separate .so - that then allows us to clean up the API to be clean - a little bit at a time, and once its clean to be split entirely - split it. this way it stays in head - and we have minimal breaks. :) > Vincent > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > enlightenment-devel mailing list > enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ra...@ra... 裸好多 Tokyo, Japan (東京 日本) |
From: Jorge L. Z. M. <jor...@gm...> - 2007-07-25 18:07:21
|
On 7/25/07, Vincent Torri <vt...@un...> wrote: > > > On Wed, 25 Jul 2007, Carsten Haitzler (The Rasterman) wrote: > > > > be careful - then you need to deal with merging the branch - the existing > > software enigne code wont stay still forever. > > before talking about merging, maybe it's time to write some code. There > has been several times, by mails, discussions about internal changes and > absolutely no code at all is available for other devs. > The code is (and was) available (the same with other code ideas) at http://code.google.com/p/efl-research/ my fault for not telling other devs about it on the ml (as i did on the irc) but was calling for other devs to join, so now its time =) Note that currently this is just a prototype, it works right now, but now im changing how scanlines/pt functions are called so i can merge this code with the software_16 engine and have a common libary for gfx routines for two different format surfaces (ARGB8888 1 plane, RGB565 A5 2 planes, and also use a look up table for such functions instead of many conditionals. I've also changed the main data type, instead of a RGBA_Image it is a RGBA_Surface, the Image should be a wrapper on top of it. So this simple change means a lot of troubles with the current evas image loading/saving/process functions, but i think it worths :) turran. > so, if you're reluctant to merge with cvs, we have 2 solutions: > > 1) continuing the discussion by mail, hence no code will be available. > It's a wonderful way to do development. > 2) moving from cvs to another vcs, which allows merging easier than with > cvs. > > Vincent > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > enlightenment-devel mailing list > enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > |
From: Gustavo S. B. <bar...@gm...> - 2007-07-25 19:50:33
|
On 7/25/07, Jorge Luis Zapata Muga <jor...@gm...> wrote: > On 7/25/07, Vincent Torri <vt...@un...> wrote: > > > > > > On Wed, 25 Jul 2007, Carsten Haitzler (The Rasterman) wrote: > > > > > > be careful - then you need to deal with merging the branch - the existing > > > software enigne code wont stay still forever. > > > > before talking about merging, maybe it's time to write some code. There > > has been several times, by mails, discussions about internal changes and > > absolutely no code at all is available for other devs. > > > > The code is (and was) available (the same with other code ideas) at > http://code.google.com/p/efl-research/ my fault for not telling other > devs about it on the ml (as i did on the irc) but was calling for > other devs to join, so now its time =) > > Note that currently this is just a prototype, it works right now, but > now im changing how scanlines/pt functions are called so i can merge > this code with the software_16 engine and have a common libary for gfx > routines for two different format surfaces (ARGB8888 1 plane, RGB565 > A5 2 planes, and also use a look up table for such functions instead > of many conditionals. > > I've also changed the main data type, instead of a RGBA_Image it is a > RGBA_Surface, the Image should be a wrapper on top of it. So this > simple change means a lot of troubles with the current evas image > loading/saving/process functions, but i think it worths :) we'll end with SDL :-/ It's SDL_Surface is just like that, but I don't see any other way. -- Gustavo Sverzut Barbieri -------------------------------------- Jabber: bar...@gm... MSN: bar...@gm... ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 |