Jorge writes:
> > I tell you what, let me look things over a bit during the
> > weekend, and if you like you and maybe Jorge can do the same...
> > maybe discuss it with others on the list who have some experience
> > with evas/objects/engines.... and we can take it up again on Mon
> > or Tues, and maybe Carsten can add some thoughts.
>
> i think we need to actually write what are our main goals with
> this, not only "rewrite some internal evas stuff". what i would
> like to have on evas is:
>
The issue is not to "rewrite some internal evas stuff" just
for the heck of it.. It's to fix a large number of aspects that
prevent the lib from scaling to support much more than what it
now does.. and prevent it from supporting even slight additions
without a large amount of effort.. and a few other things as well
that need to be fixed.
Unfortunately, to do this right means re-writing much of
the internals.. no simple little piece-meal 'patches' are going
to do it.
> - simplify the creation of render engines.
> - support font engines. freetype should be one of them.
> - make objects be modules too
> - actually make objects render by themselves to an argb buffer
> - split huge headers into smaller ones.
> - support for a mechanism to make evoak work nicely with evas
> (callbacks, remote engine, whatever)
> - (add more)
>
Much of this cannot be done in 'isolation' without a coherent
view of the final target design/capabilities that one wants the lib
to have.
Let me address some of the above, as I see things...
-- "support font engines. freetype should be one of them."
I hope you realize what a pain font/text related stuff is!
I would say that this is not really that important right now, but is
certainly something to be kept in mind.
Long ago (or so it seems), I wrote font loaders for imlib2.
At the time, freetype didn't support xfonts so I had loaders
for ttf fonts, xfonts, and fnlib fonts. I also had "font stylers",
which were also loadable modules and could 'style' any input glyphs..
I had something like three such 'stylers' I think.
They could layer/composite glyphs, texture them with images
or grads, bumpmap them with light sources, shadows, rotate/skew them,
modify glyph advances, and other things.. xml files described what
they would do.
Unfortunately, I had to break the imlib2 api to do this
since it wasn't adequate for the needs of such beasties... Carsten
may still have the code for this somewhere as I sent it to him then.
-- "simplify the creation of render engines."
This, per se, needs at least three things to begin with,
as I mentioned earlier: get/put and composite argb buffer functions,
and also a generic cache mechanism. This latter is needed for several
things.. least of all to cut back on needless code duplication.
I hope everyone knows that if you call the evas api function
"evas_image_cache_set(evas, size)" you will not only be setting the
cache size for that 'evas' instance, but also for every evas that
uses the same engine.
If some code sets the cache size to 0 for one software-x11
evas canvas, they will have flushed the image cache and set it to 0
for every software-x11 evas the program/lib deals with, and also
flush the more "common" image cache that all buffer-evases use.
If some code somewhere sets the image cache to 0 for one
buffer evas instance, it will flush the image cache for all such
and there will be no further image caching by any buffer evas, or
ecore sub-canvases, until some other code resets the cache size for
one buffer evas somewhere...
I wrote a simple quick one once as well, using the current
evas hash/list implementation and following the basic pattern used
for image caching, etc.. It had a fairly straightforward api which
Carsten and I discussed somewhat.
But to stick this into evas requires a moderate amount of
work, and as no one seems concerned with the above caching issues
or with the internal code duplication, so I just let it go.
This kind of thing is something that ecore could use as well
though.
Now, as to the get/put and composite funcs.. that's fairly
straightforward.. although to do this at all would be best done in
conjunction with the move to premul data, which together forms not-
so-small an amount of work.
-- "make objects be modules too."
Ahhhhh.... This is something I've been mentioning for months,
but no one seemed to care about. I sent Carsten some preliminary notes
on this, some data structures and design preliminaries needed, etc..
But it requires a lot of work to fully realize this - to make
it work in tandem with loadable types and arbitrary engines.. and no
one seemed much interested in this. Should I further pursue such a
large re-write, which no one has much enthusiasm or support for, and
then just throw it over...?
-- "split huge headers into smaller ones."
Which headers? For what internal changes?????
-- "support for a mechanism to make evoak work nicely with evas
(callbacks, remote engine, whatever)"
A truly nice capability.. :)
-- "(add more)"
Just the above is quite a bit.. It would make this part much
easier. Many things are actually fairly simple to do.. it's adding
them to evas with its current internals that is "difficult".
> >
> > This is the kind of thing that would really benefit from
> > having an "experimental" CVS version of evas.. Understand though
> > that it would mean quite a bit of work to get it all done.. a lot
> > has to be re-written.
>
> indeed, a cvs dir to experiment with evas would be nice, maybe
> i can put it on proto?
>
It's going to be just about impossible to do this any other
way than with a separate CVS version to work with.
To me the main issue is not really a 'technical' one pre se,
it's do people really want, and want to help with, such changes?
jose.
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
