Re: [E-devel] [e-users] Terminology - time to talk.
While I'm around here wishing Jorge a happy birthday, now seeing this flurry of controversy... David Seikel wrote: > We have a fundamental disagreement about the need for changing > something that works quite well. Does not sound like any of us are > gonna change the minds of the others. > > Gustavo and I are gonna be a tough audience, but trust me, people > outside the EFL project are gonna be even tougher. Gustavo and I at > least WANT to use it, if it measures up to our standards, coz it's EFL > and looks great in other respects. A lot of people are gonna react > with "WTF is this shit bling, where the hell are the tabs. Useless > piece of crap.". And some will say that even if you DO have ALL the > functionality, but you should at least have all the functionality. > > We don't HAVE to create something new, certainly we don't HAVE to be > shiny. Doing things just coz it's shiny is not gonna go down well for > something as utilitarian, plain, and boring as a terminal program. > Bling for the sake of bling just wont go down well among the users of > these things. You can add all the bling you want, just make sure that > if you are using bling instead of previously working functionality, > that you think through all the uses of that functionality, and don't > leave anything out. Don't leave out functionality just coz you don't > like it, when it should be obvious by now that other people are > passionate about it. > > You wont convince us with argument, we wont convince you. Show us the > code if you think it can be "better". Then we can review what you > actually make, and decide if you have satisfied our use cases. > > So make your blingy tab substitute, but those of us that like and use > tabs are watching, and we will bitch loudly if what you make is a > backwards step for the functionality we want. Then one of us will make > tabs anyway. :-P > > Options are good, not everyone thinks the same. > > Those who've been around here long enough know that I'm not one to go around defending Carsten a whole lot, but in this case I have to say that it seems to me that you and Gustavo are probably over-reacting somewhat. The man has an idea of a way that he thinks might be nice, maybe 'better', etc... Well, let him give it a shot. You may even end up liking the new way once he's done with it... Or not, but at least give the man a chance to try it to his satisfaction without killing him for daring to think differently. If it's not to your liking at all, then it's conceivable that one could also have your more classic notion of tabs within the same terminology app by maybe adding a 'multiple-views' configuration mode, one mode being Carsten's idea and another mode your more classic tabs idea (maybe you or Gustavo could implement it). So long as a given theme would support both modes, one could conceivably change between them as suits your taste. If it's feasible to implement, then it would give the 'options are good' you want... I doubt Carsten would object to that kind of flexibility for this terminological app. Don't forget the cup of coffee, Jose. 53 Year Old Mom Looks 33 The Stunning Results of Her Wrinkle Trick Has Botox Doctors Worried http://thirdpartyoffers.juno.com/TGL3141/4fe1b255e7a1a88013st02duc -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EFL and Webkit
Carsten Haitzler (The Rasterman) wrote: > >> Either way, this would allow for engine-specific extensions >> for evas.. wrapping things adequately would allow for things like >> say an "evas3D" lib if really desired. > > sure. 3d INSIDE a "3d object" i can deal with in evas :) > Exactly. Wrap things say a 3d-scene object and do your 3d stuff 'inside' such an object. One can do both immediate-mode and retained- mode kinds of rendering to such a scene object. For the latter type, one could have auxiliary 3d objects which must be 'bound' to such a scene, with coordinates rel to the scene obj,... eg. a 3d-scene object itself might be one such object that one could add to another, and ideally all evas primitives would also be added to such a 3d-scene object. One can extend evas in various ways by suitably having such objects which are like 'canvases' themselves that may support their own kinds of rendering/object system... things like 3d, svg, html, and many others are all possible in this way. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Systray - Ideas for a new spec
Samuel (lok) wrote: > Mixing iiirk and notification together would provide over 90% > of what a tray does. Add to that IBar/IBox and you get something > near OS X dock. Of course any other combination is possible. What's an "iiirk"? - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] evas (and other canvases) reviewed by gtk folk
Here's a vision: Vincent wrote: > While reading an article about gtk+ 3 (from osnews), i have found a page > about different canvases: > > http://live.gnome.org/ProjectRidley/CanvasOverview > > and evas is mentioned. Also, i think that there are some errors about > evas, and some missing stuff. > > Do you think it is worth mentioning that to the guys who wrote that page ? > Not really. In any case, the issues of using a 'canvas' for gui development are more involved than what's listed there. Havoc Pennington has a fairly good post recently on the gtk- devel list about that (in relation to the 'future' of gtk). Many of those things have been addressed already by others in one form or another. Right now, there are several fully or partly foss projects out there which do this.. "e" can be considered one such, and qt in part, but there are others like Mozilla, Flex, JavaFX, and of course the not-so-foss WPF. Frankly, unless the "g" community has a clearly better vision than any of these, then it might simply be better for them to adopt one such and just let gtk fade away. But that's a hard thing for people to do - prior time and effort invested, personal influence, corporate backings, and such. Here's a vision: A new breed of young, hungry desktop *and* web developers, fed up with the limitations imposed by the aristocracies of the "g", "q", "e", ... embrace Mozilla and develop a complete web/desktop/embedded "rich" stack -- Behold, the rise of "m"! Scary... :) - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] more works and fixes for wallpaper fetcher
Massimiliano wrote: > > > Might I suggest exporting the efreet xml parser and use it > > > instead? Does anyone object? Using strstr to parse xml isn't > > > very nice. > > > > > > Sebastian > > > > On my side i don't have any preference, i initially wrote my > > parser 'cause i've to parse a very small subset of tags, and > > i rewritten it to make it better/faster and to have support for > > media namespace. But if you think that efreet's parser is better/ > > faster, feel free to change. > > > > Thx > > > > Massimiliano > > Still waiting for replies? > I can't say that I've followed what this is about.. but if it's something like wether "e" should have a good xml parser/api vs. everyone who needs something like that having to write their own... then I'd say it may be time for "e" to stop 'poo-poo-ing' xml (mostly an excuse to avoid dealing with it) and consider developing some solid support for it - for those that may wish to NOT write their own when they need to use xml. Like it or not, xml is here and not going away any time soon, its use is almost universal - especially across the web, but also locally as well. PS. Wasn't there "exml" supposedly to deal with this? Or is that another lib that has serious flaws or limitations? - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ewl widget positioning
Dan wrote: > Currently Ewl positions widgets based on absolute coordinates. This > works but isn't unnecessarily optional. Thoughts on changing the > internals of Ewl to use parent relative placement of widgets? > > This would, hopefully, simplify some of the container code and allow > for more code re-use internally. > > We would need to convert all containers to a relative layout and > modify the theme system to map the coordinates properly. > > This would cause issues if we do need to place a widget absolutely, > as we'd need to walk the parent tree to figure out where we were, > but, how often we need to do this I'm not sure. > > Thoughts? > dan Don't know myself. But if this would be a useful internal step to get something like a "canvas" container widget in ewl (and etk) which would allow for arbitrary positioning of child widgets, then that would be a great thing indeed. Such a canvas widget would give the toolkits some much needed flexibility - allowing for things like widget/obj animations, custom/arbitrary layout mechanisms much like evas does with smarts (possibly via deriving other widgets from canvas), and a host of other things. Very important for developing "rich" apps. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] more works and fixes for wallpaper fetcher
> >I can't say that I've followed what this is about.. but if > > it's something like wether "e" should have a good xml parser/api > > vs. everyone who needs something like that having to write their > > own... then I'd say it may be time for "e" to stop 'poo-poo-ing' > > xml (mostly an excuse to avoid dealing with it) and consider > > developing some solid support for it - for those that may wish > > to NOT write their own when they need to use xml. > >Like it or not, xml is here and not going away any time soon, > > its use is almost universal - especially across the web, but also > > locally as well. > > > > PS. > >Wasn't there "exml" supposedly to deal with this? Or is that > > another lib that has serious flaws or limitations? > > > > Why write our own when libxml2 works quite well? Seems like needless > NIH to me. I agree. The only thing would be that one may want to have a wrapper lib(s) that expose a certain api which might be more convenient or easier or better fit to whatnot, etc. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ewl widget positioning
> You can do this now with Ewl. The only problem being, everything > is absolute coordinates which is a bit strange for this kind of > widget. If you want to do this, inherit ewl_box, remove configure > event, add your own configure and use ewl_object_place to put the > widgets where you want them. (Or, alternatively, I think this is > what ewl_overlay does already but I haven't used the overlay). However you have it (though rel coords would seem best), if you really want ewl to be a flexible tool for building artistic, rich apps, then you'll want a natural way to arbitrarily position child *widgets* - not just evas objects.. and to allow for custom kinds of child widget layout mechanisms. One should not have to 'go-out' of the toolkit based widget framework (and into evas say) in order to develop 'rich' apps. It's not enough to have such abilities only with evas objects, or that you can do this and that and then... It has to be a basic feature of the toolkit itself. But those are just my thoughts on it, others might see things differently. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ewl widget positioning
> >However you have it (though rel coords would seem best), > > if you really want ewl to be a flexible tool for building > > artistic, rich apps, then you'll want a natural way to > > arbitrarily position child *widgets* - not just evas objects.. > > and to allow for custom kinds of child widget layout mechanisms. > > This is currently what the overlay container is for, but it's > based on absolute coords. Ah, ok.. interesting :) U... let me ask you this, just as a kind of 'academic' question: How natural (or easy/straight- forward) would it be to write something like 'expedite' with ewl - without the engines or performance stuff, or the actual kinds of gfx things.. just the 'demo' like aspect using say images and maybe some other kinds of widgets (buttons, labels, whatever..)? Or something like that anyway.. But no falling back to 'evas'. :) - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ewl widget positioning
> > >However you have it (though rel coords would seem best), > > > if you really want ewl to be a flexible tool for building > > > artistic, rich apps, then you'll want a natural way to > > > arbitrarily position child *widgets* - not just evas objects.. > > > and to allow for custom kinds of child widget layout mechanisms. > > > > This is currently what the overlay container is for, but it's > > based on absolute coords. > > Ah, ok.. interesting :) U... let me ask you this, just > as a kind of 'academic' question: How natural (or easy/straight- > forward) would it be to write something like 'expedite' with ewl - > without the engines or performance stuff, or the actual kinds of > gfx things.. just the 'demo' like aspect using say images and > maybe some other kinds of widgets (buttons, labels, whatever..)? > Or something like that anyway.. But no falling back to 'evas'. > :) > > Just to make it a bit more flexible though, let's also allow for 'importing' evas objects - if possible (not sure if ewl has this at the moment, but just in case). But the app should be a ewl app that 'demos' ewl widgets, in a rich, cinematic way.. with a main interface much like the current expedite. It should not be an ecore_evas app that has widgets embedded in evas objects though - that's interesting too, but not the point of the exercise. Is something like that natural to obtain with ewl and its overlay widget? - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] more works and fixes for wallpaper fetcher
Massimiliano wrote: > > Why write our own when libxml2 works quite well? Seems like > > needless NIH to me. > > The module lives inside E, so i think isn't good to add another > dependecy for E. Ah, good man. You've been thoroughly indoctrinated into avoiding the evil influences of 'dependencies' in 'E', now it's even for e17 modules! Indeed, I wonder how many systems e17 is going to run on that have absolutely no trace of any use of xml on them, or that don't already have libxml2 installed. So, instead, "e" should have everyone who needs to parse xml write their own.. again, and again,... Far better that way. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] more works and fixes for wallpaper fetcher
Massimiliano wrote: > 2008/3/20, Jose Gonzalez <[EMAIL PROTECTED]>: > >> Ah, good man. You've been thoroughly indoctrinated into >> avoiding the evil influences of 'dependencies' in 'E', now it's >> even for e17 modules! >> >> Indeed, I wonder how many systems e17 is going to run on >> that have absolutely no trace of any use of xml on them, or that >> don't already have libxml2 installed. >> So, instead, "e" should have everyone who needs to parse xml >> write their own.. again, and again,... Far better that way. >> >> > > Hmmm, i think that there'a a lack of understanding. The module i wrote > isn't a module like start or wlan or news, it doesn't reside on > e_modules/ dir, but you can find it into > e17/apps/e/src/modules/conf_wallpaper, hence my desire to avoid > external dependencies. > > Look, I personally think it's great that you've done all this - it's a great exercise and a cool and useful feature, and you should be free to choose to do it in whatever way you deem best. :) But I hope you realize that it's just not a reasonable solution to the general issue of "dealing with xml in e" - and that's what we're pointing to here. Indeed, I believe that's why someone(s) wrote libxml2 in the first place (perhaps someone much like you), to address such an issue for the benefit of others. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas Object Size Hints
> > In general I don't have any objections to the addition of size > > hints to Edje, these could actually be useful to EWL as we could > > use them in place of some of the existing size hints we get from > > Edje. I'm not really certain why you want the ability to set the > > min and max sizes programmatically since these are normally > > determined by the EDC description, but I don't really see a > > problem with it. It might be a > > the problem comes when you swallow something into a edje - it does > not know the constraints of the object being swallowed - thus edje > has calls like: > > edje_extern_object_min_size_set() > edje_extern_object_max_size_set() > edje_extern_object_aspect_set() > > these attach hints via a generic data + string key attaching > mechanism so edje can pick them up when swallowing. of course > formalising these as intrinsic properties of an evas object > would make this cleaner and provide more usefulness for other > things. > Yeah, but that's just so that you can *get* the min/max sizes - because there's no other way since arbitrary evas objs don't have such min/max_size properties. If they did, you could just 'get' them. These min/max values could actually change, as other properties of the object (which can be 'set') are varied, due to internal constraints and whatnot, but it makes little sense to 'set' the min/max values of anything that's potentially intrinsic to an object. Does it make sense to set the min/max values of the min_size property? One can imagine setting lower/upper bounds for values of properties (subject to those being constrained by the min/max ones), with the meaning that setting arbitrary values for the property will be stopped at those limits, but not really directly setting min/max ones. It's a bit of a semantic run-around, but not any more mojo than the usual. :) - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas Object Size Hints
Carsten wrote: > > > > > > edje_extern_object_min_size_set() > > > edje_extern_object_max_size_set() > > > edje_extern_object_aspect_set() > > > > > > these attach hints via a generic data + string key attaching > > > mechanism so edje can pick them up when swallowing. of course > > > formalising these as intrinsic properties of an evas object > > > would make this cleaner and provide more usefulness for other > > > things. > > > > > Yeah, but that's just so that you can *get* the min/max sizes > > - because there's no other way since arbitrary evas objs don't > > have such min/max_size properties. If they did, you could just > > 'get' them. > > > > bingo. that's the whole point of it - set them, be able to get > > them, have callbacks and events when they change (just like resize, > > move etc.). > > Not quite. The question is: what sense would there be in *setting* the min/max_size values on any object - period. The object could have non-trivial such values, due to internal constraints on its current state, but you wouldn't *set* these directly via an api func - the object calculates them and gives you those min/max values.. ie. you can *get* such things via an api function. But there's no sense that I can see in an api function to *set* them. I can imagine setting min/max_size_hints, and understand various possible semantics for it, but that's not the same as an object's min/max_size. The former would still be constrained by the latter, and only the object can determine the latter. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas Object Size Hints
Gustavo wrote: > anyone really looked at the patch? It says it all :-) > > I saw the patch. But it refers to size 'hints', and still leaves open the question of obtaining an object's min/max size. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas Object Size Hints
I wrote: > Gustavo wrote: > >> anyone really looked at the patch? It says it all :-) >> >> >> > I saw the patch. But it refers to size 'hints', and still leaves open > the question of obtaining an object's min/max size. > > Let me be a bit more precise here: 1) Is it desirable to obtain an object's min/max_size? 2) If it is, then: is it a good idea to have a separate api function to get those values, or do you intend that eg. to obtain the min_size, one should always be able to do: evas_object_size_hint_min_set(obj, w = 0, h = 0); evas_object_size_hint_min_get(obj, &w, &h); - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas Object Size Hints
Gustavo wrote: >> Let me be a bit more precise here: >> >> 1) Is it desirable to obtain an object's min/max_size? >> 2) If it is, then: >> is it a good idea to have a separate api function to get those values, >> or do you intend that eg. to obtain the min_size, one should always >> be able to do: >> >> evas_object_size_hint_min_set(obj, w = 0, h = 0); >> evas_object_size_hint_min_get(obj, &w, &h); >> > > I see what you mean, but I don't think we really need this, at least > now. If we need this some day, we can extend it either by adding some > range set and clamp to this range in setters, or we could add > interceptors and make it generic. But adding these now, without a > valid use-case (at least a real life, either in Edje, EWL or ETK) is > over engineering. We can extend it later without breaking the API. > > Also, note that we callback on any size_hint setting, so object itself > can listen for those in order to revert values. It will not be > "atomic" and it might generate infinite loop if 2 peers bounce, but it > will do for most of cases. > > What do you think about it? I'd leave it as is for now and possible > add this noted in the comments. > > I don't know. If edje objs feel it's important to have min/max sizes then why not for other kinds of objs? Also, when an edje that swallows another obj computes its min/max size, why not use the same such for those objs - why something else? Or, if 'hints' are all that's needed for other objs, then why not for edje ones too? etc.. In other words, a lot of this seems artificial and arbitrary either way - except that getting min/max sizes at least has a semi-intuitive semantics, whereas 'hints' has a rather ambiguous semantics for its effect by comparison. In other words.. I have no idea. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas Object Size Hints
Carsten wrote: >> via an api func - the object calculates them and gives you those >> min/max values.. ie. you can *get* such things via an api function. >> But there's no sense that I can see in an api function to *set* them. >> > > of course there it - smart objects. they need to be able to set their own. > > Never mind. :) - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] part_swallow as embryo function in edje
Gustavo wrote:
> On Tue, Mar 25, 2008 at 10:39 PM, Santiago Aguiar
> <[EMAIL PROTECTED]> wrote:
> > Hi everyone!
> >
> > I started working with edje yesterday (always a lover of e,
> > but I was amazed in Dave Andreoli's presentation at bossa
> > conference!) and second thing I wanted to do was to include
> > a group as a swallowed object of a part :) . I thought it was
> > a good way to reuse the group multiple times, and for example
> > define a button bar and use it in multiple places, but
> > constrained by the swallowing part geometry.
>
> Ah, great to hear Bossa is bringing new people to the project :-)
>
>
Sure is, and I'd bet many people would be interested in seeing
Dave's presentation as well. :)
> > I couldn't find how to do it using edje+embryo, but I was
> > able to do it using python-efl. So I wrote a patch to add
> > a part_swallow function to the edje exported embryo functions
> > as a way to do this directly without external code. Now I can
> > do something like:
> >
> > program {
> > name, "init";
> > signal, "load";
> > script {
> > part_swallow(PART:"button_bar", "Group_Button_Bar");
> > }
> > }
>
> Maybe we can find out some other use case for this function
> (ie: select which part based on some runtime parameter, like
> time, signals, messages...), but for instance the code you did
> there can be avoided by use of parts of "type: GROUP" using
> "source: "button_bar"", see
> http://docs.enlightenment.org/api/edje/html/edcref.html
> but it should look like:
>
> part {
> type: GROUP;
> source: "part_name";
> description { ... }
> }
>
That's right. The GROUP part type was added for two main
reasons: One was to begin to have some re-usability of components
in edje (at the edje/edc level at least), and the other was to allow
one to build trees of edje groups via the edje/edc syntax.
Brian (rephorm) and I had discussed several other enhancements
to edje to allow for such things as: a 'styling' mechanism that would
allow for changing part description attribute values, a notation for
such things as 'extending' or 'overriding' referenced group defs,
allowing for group parts to be referenced from group defs in other
files, more scripting power, and other things.
But we both got sidetracked with other things and never had
a chance to follow up this. :(
-
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
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] part_swallow as embryo function in edje
Gustavo wrote: > On Wed, Mar 26, 2008 at 10:17 AM, Santiago Aguiar > <[EMAIL PROTECTED]> wrote: > >> I changed the patch to reflect Gustavo's comments. >> >> I left the part table lookup to keep the compile time check (besides >> most embryo wrapper functions do something similar). Would it be ok to >> add a GROUP:"name" construct to edc? >> > > Now it looks perfect :-) If nobody else spot problems I'll commit later today. > > As for GROUP:"name" it would be great and could help in the case of > "type: GROUP", but I fear most for compile time checks, as converting > them to numbers/integers will not help much. > > Extend embryo scripting to have a swallow function (even if it's to be restricted to swallowing only other edje groups) seems like a nice addition.. complements the internal edc GROUP part very well. But what do you mean by: add a GROUP:"name" construct to edc? - 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] part_swallow as embryo function in edje
Santiago wrote: > I wrote a patch that does the compile time check of the group name > when adding a GROUP: tag. Now the part_swallow embryo function > *requires* the second parameter to be tagged by GROUP: and refer to an > existing group. > > The following patch includes both the part_swallow embryo function > (without modifications to the previous patch except on the embryo > prototipe declaration) and changes to src/bin/edje_cc_out.c to add the > GROUP: check. > > I will be more than grateful for any corrections or comments :)! > Well, generally speaking, it looks pretty good to me (from a quick scan of it - likely raster, gustavo, cedric could give you better feedback though). I wonder how you see this kind of things being used - maybe run-time changing of swallowed groups (triggered by signals), or maybe something else? In any case.. nice stuff. :) As someone who's fairly new to edje, what other things do you think might be useful to have? - 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] part_swallow as embryo function in edje
Gustavo wrote: > On Thu, Mar 27, 2008 at 1:46 PM, Jose Gonzalez <[EMAIL PROTECTED]> wrote: > >>Gustavo wrote: >> >> > On Wed, Mar 26, 2008 at 10:17 AM, Santiago Aguiar >> > <[EMAIL PROTECTED]> wrote: >> > >> >> I changed the patch to reflect Gustavo's comments. >> >> >> >> I left the part table lookup to keep the compile time check (besides >> >> most embryo wrapper functions do something similar). Would it be ok >> >> to add a GROUP:"name" construct to edc? >> >> >> > >> > Now it looks perfect :-) If nobody else spot problems I'll commit >> > later today. >> > As for GROUP:"name" it would be great and could help in the case of >> > "type: GROUP", but I fear most for compile time checks, as converting >> > them to numbers/integers will not help much. >> > >> > >> Extend embryo scripting to have a swallow function (even if it's >> to be restricted to swallowing only other edje groups) seems like >> a nice addition.. complements the internal edc GROUP part very well. >> But what do you mean by: add a GROUP:"name" construct to edc? >> > > That would validate if the "name" is a group of that file, as it does > for PART:"name", but unlike part-variant it would not translate it to > an integer. > > I don't know the internals to say if it's easy or not, very useful or not... > > Me neither. But it stands to reason that one should be able to do with embryo scripting whatever the c api can do (more or less). In fact, it'd be interesting if edje could allow for more than just embryo scripting (eg. have python, ruby, ... types of scripts also inlined in the edc file). PS. How goes the evas filters/transforms/general-clipping stuff? :) - 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Re: EFL and Webkit
Vincent wrote: > .. >> >> Then go from there and build things like an evas-3D lib if >> desired.. possibly dependent on gl but able to render to any evas by >> say rendering to a gl buffer and getting argb data if need be, or some >> other way.. > > just to mention that the direct3d engine can also do (obviously) 3d. > Currently, the d3d engine can not, but i have a new engine which uses > vertex buffers, like the open gl ones. Maybe it would be interesting > to support both api. > Well, if you just expose 'native surfaces' then you don't need anything more - you just draw to those with whatever libs/apis you want. But there are other ways too, eg. one could have engine specific evas objs which would allow you to specify certain obj-funcs, a 'draw' func in particular. In any case, the idea of having something like a 3d-scene object would be to abstract away from such specific apis like gl or direct3d. What api could it provide instead? Well, that could vary from something that simply allows one to 'set' a file on such an object and it'd just load a 3d scene description and maybe allow one to change some stuff... or it could give a set of primitive objs, or have some sort of high-level 3d api, or whatnot. Of course it could still allow you to use low-level apis like gl or direct3d where appropriate. What is needed here though, is *one* concrete mechanism worked-out. > maybe we whould also look at gallium for 3d. > As this would give...??? - 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Unified theme for apps
andres wrote: > @notdirectedtoanyoneinparticular: > Using Edje to theme a constricted widget library like GTK or QT would be a > complete waste of potential. The only way you will have E, EWL and ETK > looking *the same* will be creating yet another bland constricted library. > > In web design consistency (or unity) among different pages in the same > website > is attained by repeating design elements (colors, textures, fonts) and > applying the different design principles (proximity, balance, alignment, > proprortion) in the same manner across every page. > > To maintain unity among different applications unsing the same widget > library, > both GTK and QT have enforced the design principles (+behaviour) at the > programming level. This limits the designer to aesthetical changes on the > design elements. > > I assume neither E, EWL or ETK developers want to create yet another bland > library. If what I assume is correct then allow me to suggest a solution to > mantain Unity among all your apps without compromising the freedom that Edje > provides. > > Split the themes in two parts, a smaller theme file that contains textures, > fonts and colors (the design elements) and another theme file that contains > the layout and behaviour using GROUP parts to include the design elements of > the first theme file into it's own. > > Designer who want to alter themes in general limit themselves to the first > file. Designers who want to alter something specific for an specific toolkit > dives into the second. This limits designers in the second group to a extent, > they cannot simply replace a texture with another and hope it will work in > every theme, they will have to consider carefully before overrinding a design > element. Besides, they will be able of altering other aspects of the > interfaces (to different extents depending on the toolkit). > > An E, EWL or ETK application will not be a carbon copy of another. But unity > among them will be mantained. If you guys agree I can post a draft for > this "standard base theme". I have been thinking about this issue since I > started with the Edje book. > > All this might be good ideas and they could inspire people to write apps/themes in various ways. Both ewl and etk allow one to write apps that are as unique or as uniform as one wants, since both toolkits allow the writer to possibly make use of custom edjes for theming most any standard or custom component. It's up to the writer to design their app as they see fit - and that's the real power of these toolkits, that they offer that choice, rather than imposing some 'true-way'. Some set of guidelines or theme-structures could help people to write more uniform, or more unique, or more mixed, or whatever designs, and it might be useful for various situations or scenarios, but the toolkits themselves allow for those things to exist - for that kind of choice. Note also that 'theming' does not necessarily mean using edje, since you can write your app to use custom layouts and objects, and you could even create some other lib that others could use for that, along with the toolkits. In fact, with something akin to a 'canvas' widget, which allows you to arbitrarily position any widget or object, plus maybe alternative layout mechanisms, one could do pretty much anything with the toolikts - web-like looking apps, flash-like ones, etc. - 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Unified theme for apps
andres wrote: > Ok, my idea would be something like this. Split themes in two, > a "elements.edj" file and a "theme_ewl.edj", "theme_etk.edj", etc. file. > I think I covered all the necessary elements (I checked the "test" apps from > each toolkit) but feel free to extend it as you wish. > > > ... > > whatdoyouthink? > Some of this, or similar, could be used in certain ways by apps, but I think that ultimately this kind of thing would be best served by having "theme-builders" kind of apps. Maybe an extension of edje-editor, or evolve, or whatever. Likely best if it were module based so that one could write modules for building edje-based themes for various kinds of things: e17 & modules, ewl or etk generic themes, app specific themes, etc. - 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Unified theme for apps
dan sinclair wrote: > To what end? What's the point of tying them together like this? It would > be better, in the long run, to just have a single widget library instead > of 3. > > The 'one true way' of widgetry with the one true mechanism for theming, leading to the possibility of a uniform look&feel for 'all' apps? Maybe. But wether 1 or 3 or 15 widget libs, it's really the one(s) that have apps written for them that count - and of those, it'd have to be the apps that choose to use default theme elements for the standard widgets and little else. There's a pretty standard component/theming mechanism for simple web pages - html + css, and you still have the issue that people write these web pages using whatever designs they like.. and even that isn't considered enough, they want more variability and uniqueness! - 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Unified theme for apps
dan sinclair wrote: >> >> The 'one true way' of widgetry with the one true mechanism for >> theming, >> leading to the possibility of a uniform look&feel for 'all' apps? >> Maybe. But wether 1 or 3 or 15 widget libs, it's really the >> one(s) that have >> apps written for them that count - and of those, it'd have to be the >> apps that >> choose to use default theme elements for the standard widgets and >> little else. >> There's a pretty standard component/theming mechanism for simple >> web pages - html + css, and you still have the issue that people >> write these >> web pages using whatever designs they like.. and even that isn't >> considered >> enough, they want more variability and uniqueness! >> >> > > Is Edje not the one true mechanism for theme? A uniform look and feel > is nice, No it's not the one true mechanism - it's one way and that's all. > but you'd notice if you looked, Ewl allows you to override the theme > on anything you want. At any point in the widget hierarchy. And you'd notice if you read and paid attention that I've stated several times that both ewl and etk allow for that. > So, yes, I think it would be a good idea to have one widget library. > And no, I don't see why you have to lock the theme in. > > I really don't see how your html example is relevant. People can > re-theme Ewl widgets, Look deeper. > they can code in straight Edje if they want. They can even embed those > Ewl widgets into their Edje application. Guess what, they still get > variability and uniqueness. > - 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] etk?
The recent discussions here about toolkit theming and such has brought up, to me at least, the question of the future of the etk gui-toolkit. From what I can see, there has been little or no work done on this lib in a looong time -- it appears abandoned or maybe just plain un-maintained right now. Simon, etk's maintainer, hasn't been seen in a long time.. and yet there are apps out there that depend on it, eg. edje-editor which I've noticed has a bug report stating that it's "impossible to enter text correctly. Moom is working on this in etk...thanks". So, does anyone know what's up with etk.. is it dead, or sleeping, or planning big-things, or what? - 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] etk?
Simon wrote: > Hi guys, > > About the current situation of Etk, I don't think I will work on it anytime > soon > for several reasons. First of all, for the last months, I haven't really had > so > much free time to dedicate to Etk, I have been kept quite busy by a lot of > things such as school, personnal projects, friends... I also have somehow lost > faith in this whole project (not only Etk, but the whole E project), I won't > tell more about it, but I don't think the current situation suits me. And > another important reason is that I don't think that Etk is innovative enough > to > be a real step forward... let's face it, it's "just" another toolkit such as > Gtk or Qt, that uses the EFL ok, but there is nothing really innovative about > it. > > I've recently started to work on another project that I find more innovative > and > interesting. It'll be something like Adobe Flash, but with a real toolkit > inside > it. It'll be used to create real customized GUI for application, but also to > create some gadgets or some games. In fact, something like Edje, but with > widgets and with a more powerful scripting language that will allow to have a > real control on the animation. I really have nothing to show yet and almost no > code written, just a lot of ideas in my head. I'll probably use a lot of code > from Etk for the "widget" side of the project. > > Anyway.. if anybody who already contributed to Etk wants to become the new > maintainer, I'd be glad to hear that the project is not totally dead. I just > don't think I'll work on it anymore... > > Simon > > You did some really nice work there on etk Simon, it'd be shame to see you leave it so quickly... especially since much of what you describe would be fairly straightforward to add to etk -- make the canvas widget a container that allows for arbitrarily positioned child widgets, add a timeline based animation system, maybe some custom layout mechanism, extend embryo (or other scripting language) for use with etk, extend evolve/edc suitably, ... But if you feel it's best for you to move on for now... :) Maybe others will pick up etk and carry on with it...? >> The recent discussions here about toolkit theming and such >> has brought up, to me at least, the question of the future of the >> etk gui-toolkit. From what I can see, there has been little or no >> work done on this lib in a looong time -- it appears abandoned or >> maybe just plain un-maintained right now. >> Simon, etk's maintainer, hasn't been seen in a long time.. >> and yet there are apps out there that depend on it, eg. edje-editor >> which I've noticed has a bug report stating that it's "impossible >> to enter text correctly. Moom is working on this in etk...thanks". >> >> So, does anyone know what's up with etk.. is it dead, or >> sleeping, or planning big-things, or what? >> - 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Imlib2: __imlib_hsv_to_rgb bug
Dariusz Knociński wrote: >> Hi All, >> I found bug imlib2 library (1.4.1.000) in procedure __imlib_hsv_to_rgb(...), >> old alghoritm wrong >> calculate internal values and produces bad result. I wrote new one and >> actualy testing it. This bug >> produce black bottom rect in imlib2_colorspace test program. >> Best Regards >> > I was reimplemeted __imlib_hsv_to_rgb() and __imlib_rgb_to_hsv() (s and v > range change to 0-1) and > find another problem in function __imlib_MapHsvaRange. This problem I draw on > attached picture. > I'm workingin on patch to function __imlib_MapHsvaRange. > Best Regards > That's a nice diagram there showing the differences. :) - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] The big cache patch.
Cedric wrote: > Hi, > > Let's really break everything ! This is the same serie of old patch > up to date that improve the cache system. It should not break > anything. The code is cleaner and should fix some bugs hard to track > in the current code base. > > I want to base my work on loading image in the background on this > code. So I would like people to take time to test, check their > application with it and report bugs to me. > > Have fun, >Cedric > > PS: Some engine (typically the one I can't compile like windows one) > will not be up to date. > That's a pretty hefty patch. :) Do you think you could write down some of the design/structure/etc, and what you're aiming for here.. for the sake of posterity and mere mortals with little time to look it all over. :) - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] The big cache patch.
Cedric wrote: >> That's a pretty hefty patch. :) Do you think you could write >> down some of the design/structure/etc, and what you're aiming for >> here.. for the sake of posterity and mere mortals with little time >> to look it all over. :) >> > > Yes of course. So it's basically an improvement of the current cache system. > > > > > As the code base of the cache is cleaner, it should be easier to add > new functionality. For example, I think adding the background loading > of an image surface should be really easy with this code base. > > I know that this code change is huge, and it's difficult for me to > split it as I started to do the work the old way (without git). If you > have more questions or if I am not really clear on some change, don't > hesitate to ask more question ! > Thanks. :) Actually, I do have several things I was thinking about on this, but let me just mention a kind of 'peripheral' thing you brought up - namely, that of "background loading of an image surface". I'm not sure I see what you mean by this - in evas. For local files, the images are loaded only when rendering is called and it's not clear to me what one could gain by having the loading done by a separate process (if that's what you meant)? If the files are not local, then I'd say those cases should be handled by other libs.. have the loading done to tmp local files and update those files with more data as need be (or something like that). - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] The big cache patch.
>> Thanks. :) Actually, I do have several things I was thinking >> about on this, but let me just mention a kind of 'peripheral' thing >> you brought up - namely, that of "background loading of an image >> surface". >> I'm not sure I see what you mean by this - in evas. For local >> files, the images are loaded only when rendering is called and it's >> not clear to me what one could gain by having the loading done by >> a separate process (if that's what you meant)? >> If the files are not local, then I'd say those cases should be >> handled by other libs.. have the loading done to tmp local files and >> update those files with more data as need be (or something like that). >> > > In fact on slow computer decoding file can take some time and during > this time nothing will move. > > So I am thinking about the idea of adding something like > evas_object_image_preload, that will just send the request to a > background thread. This thread will do the decompression and send an > event to the object when it is ready. If during this time you need to > access the data of the image, it will lock. This feature is needed in > my opinion if you want to do anything with many image like an image > viewer. > I see. Yeah, that could be useful.. though if an image viewer program is going to load lots of large images via such an evas api func then it could end up using a lot of resources, and if it just wants to create thumbs of such then that might be best done via another process to generate thumbnail files. But anyway, the idea could indeed be useful to have. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Evas transforms/filters/etc.
Just wondering if any progress has been made on this (eg. Gustavo, Vincent, ...?), or if anyone from the SoC is planning to give it a try? If not, then maybe I'll spend a bit of time to at least get the ball rolling on this for evas.. at least get image fill-transforms (affine ones), and see about the rest later. I personally won't do a generic clipping mechanism to include obj transforms/filters/masks/... I just don't think that kind of approach is worth it in evas (I did much of this before and didn't like it then), and would personally break things up into separate transforms, masks (image objs only), and filters (and keep clipping as it pretty much is right now). Note though that any of this means dealing with a lot of the evas image internals... Cedric. :) jose. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas transforms/filters/etc.
Gustavo wrote: > On Thu, Apr 10, 2008 at 6:00 PM, Jose Gonzalez wrote: > >> Just wondering if any progress has been made on this (eg. >> Gustavo, Vincent, ...?), or if anyone from the SoC is planning to >> give it a try? >> > > I haven't touch my development environment for a while now. This > company startup is killing all of my time, and what's left is dealing > with clients and their needs :-/ Things should be back to normal in > some weeks, then I plan to work at this, maybe it will be a client > request, who knows! ;-) > > > >> If not, then maybe I'll spend a bit of time to at least get the >> ball rolling on this for evas.. at least get image fill-transforms >> (affine ones), and see about the rest later. >> I personally won't do a generic clipping mechanism to include >> obj transforms/filters/masks/... I just don't think that kind of >> approach is worth it in evas (I did much of this before and didn't >> like it then), and would personally break things up into separate >> transforms, masks (image objs only), and filters (and keep clipping >> as it pretty much is right now). >> > > Well, what we've discussed at BossaConference, raster, cedric and > others might complement/correct me here: add a mechanism similar to > clip as it would accumulate various filters (so rotation + shear + ... > will look fine). Make a function available for the filter to query for > the output window (given these objects, what's the output bounding > box), then allocate a semi-transparent buffer and blit them all there, > apply the filter to this buffer when going to the end destination > (output buffer). This have couple of "issues", like you cannot have > filtered and non-filtered interleaved, but I think this is acceptable > given the easy it will bring to implementation and it should cover > most of the cases. Someone need to think about how to apply it to > smart objects, if we can do a automatic apply-to-all-member or provide > a specific smart api for it... for clippers, usually the smart object > creates an internal clipper and all members that should be clipped > will be clipped to it (it's in Edje, for example). But if we create a > "dummy" filter for the smart, then we might have lots of overhead if > the implementation is naive :-/ >Summary: > - similar to clip; > - filters provide a way to get the output window (bounding box) > given a set of 'filtered' objects; > - filters allocate a temporary ARGB buffer, all objects are > rendered there in order, then this buffer is filtered and the output > is placed at the screen (outbuf). Maybe the implementation will be > smart enough and filters should also return if the image should be > ARGB or RGB (ie: rotate a jpeg) and if the output have holes and > should be handled as transparent or not (rotate a jpeg = transparent > area, blur a jpeg = opaque area). These buffers can be GL Framebuffer > Objects... > - filters should work based on the output window, this will > avoid "holes" in the output for some filters (ie: rotation). Maybe it > can be flexible enough to support the other way? Does it worth to have > both? > - not clear on how to go with smart objects api, needs evaluation. > > This is exactly what I don't like.. It's complex, slow, and I feel not really needed or warranted. Most of what people really want is fairly simple - transform an object and possibly mask it with an image or gadient (itself possibly transformed), possibly with some 'effects' filter applied (pointwise or spatial), and composite with the dst surface (image objs can also have a separate fill-transfom set on them much like grad objs now allow for fill rotations). This can be done easily and efficiently via separate transforms, masks, and a certain set of 'effects' filters (blur, cmods, etc), if need be.. and avoid complexities of modifiers of modifiers of modifiers of with no clear mechanism for optimization except happy buffer land. But if everyone feels that the generalized 'clip' mechanism is the way to go.. then fine, please do carry on. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas transforms/filters/etc.
Gustavo wrote: >>> Well, what we've discussed at BossaConference, raster, cedric and >>> others might complement/correct me here: add a mechanism similar to >>> clip as it would accumulate various filters (so rotation + shear + ... >>> will look fine). Make a function available for the filter to query for >>> the output window (given these objects, what's the output bounding >>> box), then allocate a semi-transparent buffer and blit them all there, >>> apply the filter to this buffer when going to the end destination >>> (output buffer). This have couple of "issues", like you cannot have >>> filtered and non-filtered interleaved, but I think this is acceptable >>> given the easy it will bring to implementation and it should cover >>> most of the cases. Someone need to think about how to apply it to >>> smart objects, if we can do a automatic apply-to-all-member or provide >>> a specific smart api for it... for clippers, usually the smart object >>> creates an internal clipper and all members that should be clipped >>> will be clipped to it (it's in Edje, for example). But if we create a >>> "dummy" filter for the smart, then we might have lots of overhead if >>> the implementation is naive :-/ >>> Summary: >>> - similar to clip; >>> - filters provide a way to get the output window (bounding box) >>> given a set of 'filtered' objects; >>> - filters allocate a temporary ARGB buffer, all objects are >>> rendered there in order, then this buffer is filtered and the output >>> is placed at the screen (outbuf). Maybe the implementation will be >>> smart enough and filters should also return if the image should be >>> ARGB or RGB (ie: rotate a jpeg) and if the output have holes and >>> should be handled as transparent or not (rotate a jpeg = transparent >>> area, blur a jpeg = opaque area). These buffers can be GL Framebuffer >>> Objects... >>> - filters should work based on the output window, this will >>> avoid "holes" in the output for some filters (ie: rotation). Maybe it >>> can be flexible enough to support the other way? Does it worth to have >>> both? >>> - not clear on how to go with smart objects api, needs evaluation. >>> >>> >> This is exactly what I don't like.. It's complex, slow, and >> I feel not really needed or warranted. >> Most of what people really want is fairly simple - transform >> an object and possibly mask it with an image or gadient (itself >> possibly transformed), possibly with some 'effects' filter applied >> (pointwise or spatial), and composite with the dst surface (image >> objs can also have a separate fill-transfom set on them much like >> grad objs now allow for fill rotations). >> This can be done easily and efficiently via separate transforms, >> masks, and a certain set of 'effects' filters (blur, cmods, etc), >> if need be.. and avoid complexities of modifiers of modifiers of >> modifiers of with no clear mechanism for optimization except >> happy buffer land. >> >> But if everyone feels that the generalized 'clip' mechanism >> is the way to go.. then fine, please do carry on. >> > > If _I_ would do it, I'd do it for usage with OpenGL or other > hw-accelerated systems, so this would map easily to them and would be > fast. > That remains to be seen - ie. just how fast a good antialias pipeline would be. Not only that though, but also wether such an approach is warranted as a basis for all engines, and maps well to common use cases, and has no 'surprises'. It's tempting to have a single mechanism, a powerful one that generalizes... but it can also be unsuitable for some things. I'd see something like that more as built-in to an immediate mode pipeline, perhaps even via the 'evas imaging' route... I just don't see such a generic method as satisfactory or necessary for the kinds of uses that evas objects would be called upon in most real-time rendering. As I mentioned, I actually did most of this before and didn't like it - unwarranted complexity that was difficult to optimize for most common cases that I could foresee.. But who knows. > However, as I said, I have no time to work on this ATM, so if you like > to try an alternative approach, please do it. Keep it as a branch > somewhere and share your results, someone may test it and see how well > it works, maybe it would suffice and this would be integrated, > everyone is happy :-) > I've already tried both approaches, and others as well. There's nothing here that's new, though there's certainly more than one way to do anything. As to some 'branch' somewhere.. maybe it's best to wait and see how your approach works out and if that would suffice, integrate it as you say. :) - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. ht
Re: [E-devel] Evas transforms/filters/etc.
I wrote: >> However, as I said, I have no time to work on this ATM, so if you like >> to try an alternative approach, please do it. Keep it as a branch >> somewhere and share your results, someone may test it and see how well >> it works, maybe it would suffice and this would be integrated, >> everyone is happy :-) >> >> > > I've already tried both approaches, and others as well. There's > nothing here that's new, though there's certainly more than one way > to do anything. As to some 'branch' somewhere.. maybe it's best to > wait and see how your approach works out and if that would suffice, > integrate it as you say. > :) > I should add that I'm in the minority here - you, vincent, and raster (maybe many others) all think that the generic 'clipping' pipeline is the best way to go. I'd just like to see one implementation of this that works well with all engines, maps naturally (in its full generality) to real-time evas obj rendering, is easy for people to use, and has no surprises/difficulties/semantic-issues/etc. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas transforms/filters/etc.
Cedric wrote: > On Fri, Apr 11, 2008 at 8:35 AM, Jose Gonzalez wrote: > >>I wrote: >> >> However, as I said, I have no time to work on this ATM, so if you like >> >> to try an alternative approach, please do it. Keep it as a branch >> >> somewhere and share your results, someone may test it and see how well >> >> it works, maybe it would suffice and this would be integrated, >> >> everyone is happy :-) >> > >> > I've already tried both approaches, and others as well. There's >> > nothing here that's new, though there's certainly more than one way >> > to do anything. As to some 'branch' somewhere.. maybe it's best to >> > wait and see how your approach works out and if that would suffice, >> > integrate it as you say. >> > :) >> >> I should add that I'm in the minority here - you, vincent, and >> raster (maybe many others) all think that the generic 'clipping' pipeline >> is the best way to go. >> I'd just like to see one implementation of this that works well with all >> engines, maps naturally (in its full generality) to real-time evas obj >> rendering, is easy for people to use, and has no >> surprises/difficulties/semantic-issues/etc. >> > > I must say that I don't really see the difference between your two > proposal. Perhaps if you can propose the set of functions that will be > exported by Evas to the external developper, it will be easier to > understand and discuss. > > The main difference is that of avoiding the iterative 'clipping' mechanism as the single method for doing everything. What you want is something like: A clips B clips C clips D clips E clips F clips G clips H say, where H is eg. an image obj and G a transform obj and F a rect obj and E a blur filter and D a gradient obj and C a . with the result of obtaining a transformed image which is multiplied by blurred rect which is multiplied by gradient which is then composited to the dst. Also, some of these clippers may be clipping other objs. Very succint, very extensive... very likely to be difficult to optimize for simple, commom-use cases, and even more likely to not be used in this kind of arbitrary generality. Also likely to be problematic with smart objs and difficult to use for basic things.. imagine setting a trnasform on an image obj that's already had a rect set as a clip - one'd have to unset the rect clipper, set the transf as the new clipper, and set the rect as the clipper of the transform.. and that's just one example of the kinds of things that come up with this approach. I'm suggesting that one avoid this temptation, leave clipping as is for now (plain rects), and instead add separate api funcs to set a geometric trnasform, to set a mask (image or grad, no masking a mask), and to set certain kinds of 'effects' filters (blur, bumpmap, ... possibly allow for chaining these). If one wants more than this, then there are several ways to obtain things - eg. introduce a 'drawing obj' type which essentially allows for one to iterate these things by allowing one to 'add' other objs to it (much like a group obj), including ones like it, and extend masks to also be of this type. Anything beyond that should probably be the domain of custom objs that can use whatever methods/apis they have access to.. gl, shaders. whatever. But keep the core, built-in stuff simple, efficient, natural and also flexible enough to obtain more complex things if desired. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas transforms/filters/etc.
Gustavo wrote: >> The main difference is that of avoiding the iterative 'clipping' >> mechanism as the single method for doing everything. >> What you want is something like: A clips B clips C clips D clips >> E clips F clips G clips H say, where H is eg. an image obj and G a >> transform obj and F a rect obj and E a blur filter and D a gradient >> obj and C a . with the result of obtaining a transformed image >> which is multiplied by blurred rect which is multiplied by gradient >> which is then composited to the dst. Also, some of these clippers >> may be clipping other objs. >> >> Very succint, very extensive... very likely to be difficult to >> optimize for simple, commom-use cases, and even more likely to not >> be used in this kind of arbitrary generality. Also likely to be >> problematic with smart objs and difficult to use for basic things.. >> imagine setting a trnasform on an image obj that's already had a >> rect set as a clip - one'd have to unset the rect clipper, set the >> transf as the new clipper, and set the rect as the clipper of the >> transform.. and that's just one example of the kinds of things that >> come up with this approach. >> >> I'm suggesting that one avoid this temptation, leave clipping >> as is for now (plain rects), and instead add separate api funcs to >> set a geometric trnasform, to set a mask (image or grad, no masking >> a mask), and to set certain kinds of 'effects' filters (blur, bumpmap, >> ... possibly allow for chaining these). >> > > Well, you misunderstood me then. > > Filters would behave like clippers, but not use the clipper mechs... I > think I tried to say that in my email. We'd have both clippers and > filters as separate lists. > > Clippers, in far, far, far.. future, will add some of what you want, > as clip to a bitmap and get a mask, clip to a gradient and get nice > fade-out of clipped items. That's what raster want to provide AFAIK. > > I don't think clippers should enable that - raster and others may though. I already implemented this once.. and didn't like it. I'd separate masking as its own operation, and leave clipping as is. As far as filters having their own api funcs but incorporating both geometric transforms and various filter effects (blur, whatnot), and chainable.. that may be ok (possibly still somewhat unwarranted for most needs). > Filters will just be filtered by filters, so it's like > "SO1(O1->F1)->F2->F3". Object O1 that is filtered by F1 and inside > Smart Object SO1 that is filtered by F2 that is filtered by F3, O1 > will get these 3 filters. >Example, F1 could be blur, while F2 be rotation and F3 be scale. > > Of course one could implement F1 as a weird filter that uses fragment > shaders to provide a fade-out effect, so eliminating the need for that > in clipper. > > That is very easy to obtain via (projective) transforms and masks (image, grads, or general 'drawing objs'), without having to invoke "fragment shaders". > >> If one wants more than this, then there are several ways to >> obtain things - eg. introduce a 'drawing obj' type which essentially >> allows for one to iterate these things by allowing one to 'add' other >> objs to it (much like a group obj), including ones like it, and >> extend masks to also be of this type. >> Anything beyond that should probably be the domain of custom >> objs that can use whatever methods/apis they have access to.. gl, >> shaders. whatever. >> >> But keep the core, built-in stuff simple, efficient, natural >> and also flexible enough to obtain more complex things if desired. >> > > they will remain like this, no existing code should be influenced by > these changes. > What does that have to do with anything we're discussing here? - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas transforms/filters/etc.
I wrote: >> Of course one could implement F1 as a weird filter that uses fragment >> shaders to provide a fade-out effect, so eliminating the need for that >> in clipper. >> > > That is very easy to obtain via (projective) transforms and > masks (image, grads, or general 'drawing objs'), without having to > invoke "fragment shaders". > One of the problems that I see with much of what you're suggesting Gustavo is that it all seems to revolve around the fact that you want to use gl or shaders or some such methods.. and all else is secondary at best. This seems extremely dangerous to me, not to mention unwarranted. What *exactly* is it that you want evas to be able to do that you feel can only be done by invoking gl and shaders? - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EFL and Webkit
Carsten wrote: >> But what I was curious about was what exactly you had in mind >> with your: >> >> typedef struct _Evas_Native_Surface Evas_Native_Surface; >> /**< A generic datatype for engine specific >> native surface information */ >> >> EAPI void >> evas_object_image_native_surface_set(Evas_Object *obj, >> Evas_Native_Surface *surf); >> EAPI Evas_Native_Surface * >> evas_object_image_native_surface_get(Evas_Object *obj); >> > > for example. if it's the GL engine u can set a GL texture ID directly as the > image native surface (u will need to provide extra info like width/height, has > alpha etc. in a small wrapper struct), or a pixmap / xrender picture for x11 > (again need to provide some extra info like visual, format etc.). so evas will > Yeah, that's what I thought you meant - though there are other interpretations possible (eg. make a gl texture native surface work even with a software-x11 canvas, if glx is available, etc.). > then take the target-specific "native surface" and just use it as if evas > owned/created it itself. this is how u'd do a composite manager - xrender > engine, you pass it pixmaps/xrender pictures for native sruface as images, you > swallow images into containers and control them. on damage events u add update > regions to the image. evas does the rest. > > What do you do if such a native surface is set and one asks for the argb data? What do you do about users setting native surfaces which don't match with the display targets somehow (differing x resources for example). I'd say - restrict native surface api to only have a 'get' func, ie. evas provides a suitable surface for you to draw to, but not for you to 'set' one such...? - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas transforms/filters/etc.
Gustavo wrote: > Filters will just be filtered by filters, so it's like > "SO1(O1->F1)->F2->F3". Object O1 that is filtered by F1 and inside > Smart Object SO1 that is filtered by F2 that is filtered by F3, O1 > will get these 3 filters. >Example, F1 could be blur, while F2 be rotation and F3 be scale. > > BTW, this is not going to work well at all with things like projective transforms (eg. ones mimmicking 3D rotations) if you want to preserve perspective and such. Because you'd need to further translate the smart members by their position rel to the smart parent and other such complications. Your best bet here is to either let the members decide what to do with the parent transform, or to 'render' the untransformed smart-obj to a buffer and transform that. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EFL and Webkit
>> What do you do if such a native surface is set and one asks >> for the argb data? What do you do about users setting native surfaces >> which don't match with the display targets somehow (differing x >> resources for example). >> I'd say - restrict native surface api to only have a 'get' >> func, ie. evas provides a suitable surface for you to draw to, >> but not for you to 'set' one such...? >> > > that would preclude evas ever being useful for a composite manager - as X > itself provides you with the pixmap of the composited window. you don't have a > choice there. > Ummm... Ok, but it would then seem as though this little piece of native-surface image hell is going to be your fun and joy when you get a chance sometime in the near future..? :) PS. I noticed you've been conspicuously quiet on the 'transforms/ filters' debate I've been putting poor Gustavo thru.. :) I'd do it but not with arbitrary clipping, using transforms (or filters) and masks instead. But maybe it's better if others give it a shot. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas transforms/filters/etc.
I wrote: >Gustavo wrote: > > >> Filters will just be filtered by filters, so it's like >> "SO1(O1->F1)->F2->F3". Object O1 that is filtered by F1 and inside >> Smart Object SO1 that is filtered by F2 that is filtered by F3, O1 >> will get these 3 filters. >>Example, F1 could be blur, while F2 be rotation and F3 be scale. >> >> >> > BTW, this is not going to work well at all with things like > projective transforms (eg. ones mimmicking 3D rotations) if you want > to preserve perspective and such. Because you'd need to further > translate the smart members by their position rel to the smart parent > and other such complications. Your best bet here is to either let > the members decide what to do with the parent transform, or to > 'render' the untransformed smart-obj to a buffer and transform that. > > Not that it's any less problematic with affine 2D ones in general.. But again, unless you want to dictate the policy that transformed smart objs should be rendered untransf to a buffer and then that result transformed, you may want instead to have smart-class functions for 'setting' a transform on a smart obj, similar to what's now done with move, resize. Also, if you want to split your transforms into 'commands' rotate, translate, etc. then to get 3D kinds of transforms you'll need to add axes to rotate around, or maybe aound a 3d vector (and maybe a focal distance). PS. I'd just set a 4x4 proj transf (you can get some funky curved stuff that way) and have utility functions for generating such in various ways (eg. for obtaining one from four dst points, for composing two transforms, etc.). - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas transforms/filters/etc.
Gustavo wrote: >> PS. >> I'd just set a 4x4 proj transf (you can get some funky curved >> stuff that way) and have utility functions for generating such in >> various ways (eg. for obtaining one from four dst points, for >> composing two transforms, etc.). >> > > Ok, trying to reply to the torrent of ideas from you ;-) > No torrent of ideas, just simple basic things that I've already run across and thought might help for you to keep in mind. >- 4x4 proj transf => good, one idea that we were considering. > That's very nice for "we". :) >- filter chaining: needs evaluation on good api to negotiate > between filters, those that can be done within the matrix (ie: just > add to transf matrix), do, others will require the intermediate buffer > and will operate on it. So Rotate+Translate+Blur would generate > Rotate+Translate in matrix, output a temporary buffer that blur would > operate on. This may be suboptimal, but is very easy to work on. >- rely on hw-acceleration (shaders and like): it's easy, it's > almost everywhere and people are gaining market share by naively using > it. We don't even allow users to use it. If you have or not such great > hardware, you're unable to use it today. So why not expose this and > let users use their hardware? Also, we can still support some of > these in software (ie: matrix transf) easily, while others we can > simple ignore.Most users (ie: E17) will try to keep with > supported-everywhere, avoiding things that might depend on hardware. > But others (ie: Rage) could try to use these fancy effects, since they > know most of their users will have such hardware. Also, we could use > Sure, and that's why things like 'native surfaces' or other methods for custom rendering would be useful - so that people can do those kinds of things if they wish. > Gallium3D or even go with LLVM directly to get some kind of JIT and > have software-only implementation that is highly optimized, without > having to care much about it ourselves. > > All in all, this "filter" thing is all about exposing some of hardware > acceleration without having to explicitly implement it in Evas (as > it's done now for things like YUV-RGB conversion, Scale, Colorize, > Fade, ...). Actually I was about to go with this individual > implementation, like adding evas_object_rotate() and like, but raster > and others convinced me that going with a generic filter > implementation would be more extensible. Going with super-fast custom > case for each of this will span a huge number of function > implementations (ie: rotate solid->solid, rotate transp->solid, rotate > transp+alpha->solid, ... all of these for C, MMX, SSE, SSE2, Altivec, > 16bpp, ...), since this is non-sense for such things that are barely > used, let's make it more generic and have the optimizations to be done > elsewhere. > Well, that sounds great! Looking forward to seeing this finally in evas. :) - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas transforms/filters/etc.
Gustavo wrote: >> >- 4x4 proj transf => good, one idea that we were considering. >> > >> >> That's very nice for "we". :) >> > > you mean because of me? Or because of others? At least raster, if you > ask him, he have tons of ideas on how to do things, he have considered > almost every case I wondered and the problems come from here: he wants > to implement the final super-uber solution to fix them all and he > never have time to do it. The only thing that I added to most things > were simpler solution to fix part of the problem and improve this > later :-P > > > Is that right.. Well now raster you evil man!! :) >>Well, that sounds great! Looking forward to seeing this finally >> in evas. :) >> > > don't be too excited... it will take time to have someone to do that. > > What! I thought you were working on this full-steam ahead.. Carsten said that's what you were doing! You're going to have to speak with him about it.. slap him around a bit and throw some frozen fish at him, it should do the trick. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas transforms/filters/etc.
Carsten wrote: >>> don't be too excited... it will take time to have someone to do that. >>> >> What! I thought you were working on this full-steam ahead.. >> Carsten said that's what you were doing! You're going to have >> to speak with him about it.. slap him around a bit and throw >> some frozen fish at him, it should do the trick. >> > > i did? where? :) i am thinking about this still - though right now i think > Nowhere, it was an exaggeration to get Gustavo and you going on this. :) > rotation should be separate to filters as such, BUT i dont preclude filters > ALSO doing rotation/shear (ie matrix transforms). simple rotation without a > filter is probably needed and i'd much sooner address that than filters, but > next up is filters. i just don't see a better way to do it other than use the > same kind of api that clippers use - clippers are in effect very simple > filters > on their own. you could have optimised paths, but as such you likely are going > to have to render to intermediate buffers, like it or not. :) > As to the particulars of this transforms/filters stuff... well, that one has to use buffers for some things is not an issue. Anyway... Since you're still thinking about all this, and since this has already been discussed at bossa, I'll drop the issue. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas transforms/filters/etc.
Carsten wrote: >> Anyway... Since you're still thinking about all this, and >> since this has already been discussed at bossa, I'll drop the issue. >> > > there is always room for input and discussion. until someone actually knuckles > down and starts doing this, discussion is good as it means we will explore all > the use cases, corner cases, issues etc. you did bring up the good point of > Ok, I'll give you some further 'input' on all this. :) Part of the problem here is that something as large and important to evas as this needs further public discussion... and mentioning decisions/discussions by an unspecified 'we', or possible feature requests by 'clients', is not a good way to get this done. I also know that adding any of this to evas is going to mean a fairly large re-working of the image internals (among other things), and that although a general 'filters' mechanism is a very powerful thing, there are many, many aspects here that need to be considered carefully. Now, despite the discussions that were done at bossa, it's clear to me that not everyone there seems to have the same idea as to just what was decided - if anything. First, it seemed that 'filters' were to be a new type of evas object which were to be used via the current 'clipping' api - at least that's what I thought was being proposed, and you, raster, did as well. Gustavo then mentioned that no, it was to be thru a similar mechanism, but not actually as clip objects. Finally, raster then further mentions something which seems somewhat like some other vague stuff I'd mentioned as well, but nothing seems particularly clear either. No mention is made of any real api for defining these 'filters' or how to deal with a variety of things like image-fills/borders, or with smart objects (apart from a vague remark about adjoining parent filters to members), or how to best implement any of this with the various engines (apart from some vague remarks about gl shaders and a gallium3d lib), or how to represent these things for use with things like edje, etc... In short, it's all been mostly a lot of vague nothing. So, does anyone have anything more concrete to propose here? Perhaps some further specifics discussed at bossa? If not, then I will suggest some. jose. PS. Some here would like to have ultimately flexible 'filters' defined via some cpu&gpu supported "shading language" (a kind of gfx scripting mechanism), but I seriously doubt that anyone here is going to spend the time and effort required to design and implement such a thing for evas. Thus, if evas' filters/transforms system is designed exclusively around such an approach, it would mean a hard dependence on eith gl-shaders or gallium3d or some such lib that would offer this functionality. I believe this should be an option.. ie. an optionally compiled, loadable ability, not a built-in requirement for evas just to allow for geometric transforms, especially since these are so easily obtained with software and readily supported in xrender and gl. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Imlib2 patch
Dariusz Knociński wrote:
> Patch:
> diff -u -p -r imlib2-1.4.1.000.old/src/lib/color_helpers.c
> imlib2-1.4.1.000.new/src/lib/color_helpers.c
> --- imlib2-1.4.1.000.old/src/lib/color_helpers.c 2007-05-21
> 00:58:01.0 +0200
> +++ imlib2-1.4.1.000.new/src/lib/color_helpers.c 2008-04-15
> 09:34:36.0 +0200
> @@ -5,117 +5,89 @@
> */
>
> void
> -__imlib_rgb_to_hsv(int r, int g, int b, float *h, float *s, float *v)
> +__imlib_rgb_to_hsv( int r, int g, int b, float *h, float *s, float *v )
> {
> - int min, max;
> - int delta;
> + register float min, max, delta;
>
> - max = (r + g + abs(r - g)) / 2;
> - max = (max + b + abs(max - b)) / 2;
> - min = (r + g - abs(r - g)) / 2;
> - min = (min + b - abs(min - b)) / 2;
> +min = ((( r < g ) ? r : g) < b ) ? (( r < g ) ? r : g) : b;
> +max = ((( r > g ) ? r : g) > b ) ? (( r > g ) ? r : g) : b;
>
> - delta = max - min;
> - *v = (float)(100 * max) / 255.0;
> -
> - if (max != 0)
> - *s = (float)(100 * delta) / (float)max;
> - else
> - {
> -*s = 0.0;
> +*v = max / 255.0;
> + delta = ( max - min );
> +if( delta == 0 )
> +{
> *h = 0.0;
> -*v = 0.0;
> - }
> - if (r == max)
> - {
> -*h = (float)(100 * (g - b)) / (float)(6.0 * delta);
> - }
> - else
> - {
> -if (g == max)
> - {
> - *h = (float)(100 * (2 * delta + b - r)) / (float)(6.0 * delta);
> - }
> -else
> - {
> - *h = (float)(100 * (4 * delta + r - g)) / (float)(6.0 * delta);
> - }
> - }
> - if (*h < 0.0)
> - *h += 100.0;
> - if (*h > 100.0)
> - *h -= 100.0;
> +*s = 0.0;
> +return;
> +}
> +*s = delta / max;
> + if( r == max )
> + *h = ( g - b ) / delta;
> + else if( g == max )
> + *h = 2.0 + ( b - r ) / delta;
> + else
> + *h = 4.0 + ( r - g ) / delta;
> + *h *= 60.0;
> + if( *h < 0 )
> + *h += 360.0;
> }
>
> void
> __imlib_hsv_to_rgb(float h, float s, float v, int *r, int *g, int *b)
> {
> - float hh, f;
> - float p, q, t;
> - int i;
> +register float f, vf;
> +register int i, p, q, t, vv;
>
> - if (s == 0.0)
> - {
> -*r = round((v * 255.0) / 100.0);
> -*g = round((v * 255.0) / 100.0);
> -*b = round((v * 255.0) / 100.0);
> +vf = 255.0 * v;
> +vv = (int)round( vf );
>
> +if( s == 0.0 )
> +{
> +*r = *g = *b = vv;
> return;
> - }
> -
> - hh = (h * 6.0) / 100.0;
> - i = floor(hh);
> - f = hh - (float)i;
> -
> - p = v * (1.0 - s / 100.0) / 100.0;
> - q = v * (1.0 - (s * f) / 100.0) / 100.0;
> - t = v * (1.0 - s * (1.0 - f) / 100.0) / 100.0;
> +}
>
> - switch (i)
> - {
> - case 0:
> -{
> - *r = round(v * 255.0 / 100.0);
> - *g = round(t * 255.0);
> - *b = round(p * 255.0);
> - break;
> -}
> - case 1:
> -{
> - *r = round(q * 255.0);
> - *g = round(v * 255.0 / 100.0);
> - *b = round(p * 255.0);
> - break;
> -}
> - case 2:
> -{
> - *r = round(p * 255.0);
> - *g = round(v * 255.0 / 100.0);
> - *b = round(t * 255.0);
> - break;
> -}
> - case 3:
> -{
> - *r = round(p * 255.0);
> - *g = round(q * 255.0);
> - *b = round(v * 255.0 / 100.0);
> - break;
> -}
> - case 4:
> -{
> - *r = round(t * 255.0);
> - *g = round(p * 255.0);
> - *b = round(v * 255.0 / 100.0);
> - break;
> -}
> - case 5:
> -{
> - *r = round(v * 255.0 / 100.0);
> - *g = round(p * 255.0);
> - *b = round(q * 255.0);
> - break;
> -}
> - }
> +h /= 60.0;
> +i = floor(h);
> +f = h - (float)i;
> +p = (int)round( vf * (1.0 - s ));
> +q = (int)round( vf * (1.0 - (s * f)));
> +t = (int)round( vf * (1.0 - s * (1.0 - f)));
> +
> +switch( i % 6 )
> +{
> +case 0:
> +*r = vv;
> +*g = t;
> +*b = p;
> +break;
> +case 1:
> +*r = q;
> +*g = vv;
> +*b = p;
> +break;
> +case 2:
> +*r = p;
> +*g = vv;
> +*b = t;
> +break;
> +case 3:
> +*r = p;
> +*g = q;
> +*b = vv;
> +break;
> +case 4:
> +*r = t;
> +*g = p;
> +*b = vv;
> +break;
> +case 5:
> +default:
> +*r = vv;
> +*g = p;
> +*b = q;
> +break;
> +}
> }
>
> void
> diff -u -p -r imlib2-1.4.1.000.old/src/lib/grad.c
> imlib2-1.4.1.000.new/src/lib/grad.c
> --- imlib2-1.4.1.000.old/src/lib/grad.c 2007-05-21 00:58:0
Re: [E-devel] Evas transforms/filters/etc.
Gustavo wrote: >> PS. >> Some here would like to have ultimately flexible 'filters' >> defined via some cpu&gpu supported "shading language" (a kind of >> gfx scripting mechanism), but I seriously doubt that anyone here >> is going to spend the time and effort required to design and >> implement such a thing for evas. Thus, if evas' filters/transforms >> system is designed exclusively around such an approach, it would >> mean a hard dependence on eith gl-shaders or gallium3d or some >> such lib that would offer this functionality. >> I believe this should be an option.. ie. an optionally >> compiled, loadable ability, not a built-in requirement for evas >> just to allow for geometric transforms, especially since these >> are so easily obtained with software and readily supported in >> xrender and gl. >> > > The point of it being generic, at least for ME (not we, don't care > about others agreeing or not) is to enable you to write such filters > and plug them. You write then, you just have to implement the API and > you're done. If you want to set a matrix, you specify it and you set > Ok, sure. But how does one implement the filters.. how do you do it so that the filters will then work with any obj, any evas, etc. One can imagine 'filters' as engine dependent modules of some sort, and then you can use whatever for implementing each.. gl shaders, software span functions, etc. Generally speaking though, most of this will work for filters that will apply to image surfaces of given types. One can also try and have an even more abstract gfx 'api' like shading languages provide, and map such to the rendering backends - but that's a lot more work. > it. If you want to be dependent on GL, do it on your code, use it from > your application. > > That was the whole point of at least having 'native surfaces' for image objs - so one could render to such surfaces via whatever specific apis one wants that could support rendering to those. Then, if one wants to use gl-shaders to do stuff on a gl texture.. great.. One could even use such gl stuff on an xrender native surface by getting a texture from the pixmap associated with a picture, etc. Lots of possibilities available for quite custom rendering to such buffers (and best utilized as part of smart objs with render-pre/post functions, and of course also via a more direct dst surface rendering mechanism). > Of course Evas should provide some good one, generic, by default. But > I'll not work on this now (maybe in future). But so far what I want is > to (_very rough_ draft of the possible API): > > Ok, but before we go on with this, let's note that there are (at least) three different ways one can imagine things like "filters" in evas: 1. One can consider filters as certain evas objects that modify the rendered region 'beneath' them (ie. in stacking order, over some region they define). This is what things like mini/magni-fication filters do, or say a blur obj that blurs the region beneath where a such an object would be placed (BTW, Hisham once implemented something like that for evas, for the software engines only.. or at least I seem to recall something like that long ago). This is potentially very interesting. 2. One can consider filters as certain modifiers which affect how a given evas object will be rendered. Now of course one can think of just about anything that way (including move, resize, color, whatnot) and it's not always useful to express everything that way.. but as you mention, one should leave open the ability to define new such kinds of filters. These are somewhat wider in scope than the above (1) since one can potentially have filters that affect only certain kinds of objects (eg. text-styles, or even fonts, can be considered as filters on text objs.. some may or may not make much sense on other types of objs). In general, for a given set of structured data (objs), we can have 'filters' that are natural to it, and some that are not (but may be for others). This is in part some of the problem we have with things like smart objs.. we even have an ambiguity with simple things like setting the color of such objs - right now we usually color each member (not much else we can do), but one could also want to color the obj as a whole (eg. as if the smart obj were rendered to a buffer evas and that image were colored). The same kind of 'issue' will come up with even more general 'filters' - even those that are geometric or raster-image- modifiers in nature. 3. One can consider filters as part of an immediate-mode api that allows one to affect other immediate-mode rendering primitives, and use such for custom rendering (to native surfaces say). There, one's able to use whatever may already exist that's appropriate. I'll try and get back to the rest of your reply once I get a chance to sleep some - but much of it is a lot like what I also had in mind. :) -
Re: [E-devel] Evas transforms/filters/etc.
Ok, let me continue where I left off last time.
We have these various kinds of notions for possible 'filters'
in evas (there are others as well, including ones that might involve
time, ie. animation related ones), but most people here would seem
to want something along the lines of (2) above, ie. filters as certain
kinds of modifiers of objects (or of rendering an object). This is
still broad since one can have filters which modify certain types of
objs and not others... but most here would at least want filters that
modify geometry and/or pixels.
As these can be interpreted as modifying surfaces which hold the
result of rendering 'objs', one could use this to extend such filters
to modify any renderable object - albeit not necessarily in a way
that might be 'natural' to the given object.
This brings up semantic issues about the possible kinds of apis
that one can use for filters.
If a filter is something that can be 'applied' to certain
types of objects thus obtaining an implicitly modified version
of the same object (or another obj of the same type), or if it's
something that can modify the way that a given type of object
is rendered, then any notion of chaining or composing of filters
should satisfy a kind of associativity property and thus lead
to a specific interpretation.
For example, let's take the original idea of using filter
objs that one can use as 'clippers', and let's say we have an
image obj which is clipped by a rect obj, and that rect obj is
in turn clipped by a geometric transform obj (say a scaling
or rotation).
Many would think the result of this would be to render an
image which is clipped by a transformed rectangle.. but that's
actually incorrect. In order to satisfy associativity, the result
would have to be the same as first rendering the image clipped by
the rect (to a buffer), then transforming that result and render it
- ie. a scaled or rotated version of an ,
NOT the image clipped by a .
Any attempt to break semantic rules such as associativity
leads to the need for further logic for determining what to do
at which step of a sequence... and makes it difficut to decide
when one can 'break out' of a chain and render to buffers or not.
This is the kind of thing that makes 'chaining' of arbitrary
filters a problem unless very strict semantic rules are followed,
and an api used which is able to naturally represent those rules.
I'll continue this a bit later, but please do jump in
with comments or whatnot if you see fit.
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas transforms/filters/etc.
> This is the kind of thing that makes 'chaining' of arbitrary > filters a problem unless very strict semantic rules are followed, > and an api used which is able to naturally represent those rules. > > I'll continue this a bit later, but please do jump in > with comments or whatnot if you see fit. > > In order to get a filter api that provides an un-ambiguous, intuitive interpretation for things, we thus need to separate this from the existing 'clipping' api - even if the 'filters' one might be similar, it still really needs to be separate (it'll also allow for greater flexibility if desired). One also really needs to make sure that the 'filters' are typed sufficiently so that it's clear that one's dealing with filters that modify a given object type, or that modify 'surfaces', etc. (of course one can consider rendering an object as a kind of filter on surfaces, with the obj to be rendered to the surface as providing part of the data that defines such a surface filter). Without that, we have the general kind of ambiguity faced with certain common filter notions like geometric transforms or coloring, where one has to decide somehow whether to interpret the effect of the filter as acting on a buffer-surface rendering of the object, or otherwise.. and this is not something unique to smart-objs. For example, in something like transf > blur > transf > polygon the first applied transform could well be interpreted as acting on vertex data, but the last applied one would likely need to be done on surface data - ie. transform a buffer surface that holds the result of blurring a rendered poly (until someone comes up with vertex data for blurry-polygons). Consider implementing the general case of this kind of thing, with arbitrary chains, with loadable filters, with any object... unless you have strict typing mechanisms and composition rules. So long as we maintain strict typing of filters, and semantic rules for filter composition, we have few problems.. otherwise, one has to be more careful in order to resolve possible ambiguities. And as soon as one starts to allow for general/loadable kinds of filters, then one really *has* to have strict typing notions. Whether it's just restricting things to abstract geometric transforms and surface (ie. image) effects, or something more general, one needs to know exactly what one is working with.. a vague 'filters for evas objects.. We can do anything!' idea is just going to lead to an absurd mess. So, what kind of api should be provided for 'filters for evas objects'? And how can general/loadable such filters be defined and obtained? Gustavo has given one possible suggestion (still needs the issue of general/loadable ones addressed, and may want to replace the 'set' with an 'add', or even an 'append/pre-pend' and others). Does anyone else have another? - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] R: Re: R: checking a part's type?
Cedric wrote: >> In all seriousness if there is love for my idea I commit to implement it. >> If there isn't, I will be more than happy with Dave's solution. >> > > Their is. It will be a real win if we can just check if an Edje_Object > really provide all the needed stuff. We could even improve it as some > type of declaration inside the EDC like the html DOCTYPE (In case we > want to check during theme creation). So I am definitevely for number > 2 (A parser + compiler and welcome .edt inside Edje). It's sound > really like a good idea to me. > Rephorm had long ago suggested further introspection abilities for edje/edc... but no one seemed interested. I've also brought up before that it may be a good idea to have better knowledge of what these '.edj' files are meant to be... - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EFL error handling
'Mickey' wrote: >>> We could put checks like this in edje_object_part_swallow. But I can't >>> help to >>> think was programmed to work this way for a reason I ignore. >>> >> All ELFs are written in this way, without error checking and reporting, i >> think it's for performance reason and I like it :) >> > > I sincerely hope that this was an ironic statement. The complete lack of > error > handling in the EFL (well, apart from image loading) is dooming like the > sword of damocles. I'm afraid as EFL gets more popular this will be a _major_ > hindrance for professional adoption and I'd really like us to revisit this > before it's too late (read: stable APIs). > > That's not entirely accurate. There's quite a bit of error checking in many of the efl, though there could certainly be much more. But there's little or no error-reporting (even the image loading stuff isn't actually correctly enabled.. at least it wasn't some time back, haven't checked recently). In evas for example, most things will simply fail "silently" in that a default state is used (eg. if image loading fails, an opaque white image is used). Whether further error-reporting, or at least some return state of fail/success is desirable... - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas transforms/filters/etc.
> So, what kind of api should be provided for 'filters for evas > objects'? And how can general/loadable such filters be defined and > obtained? > > Gustavo has given one possible suggestion (still needs the > issue of general/loadable ones addressed, and may want to replace > the 'set' with an 'add', or even an 'append/pre-pend' and others). > > Does anyone else have another? > > No other suggestions or comments yet? :) Before I suggest some possible approaches here (and frankly I'm torn between several - ranging from conservative to fairly radical ones), let me make some further comments on this.. just for fun. I've mentioned before that one needs to have strict typing of 'filters' that operate on evas objects, and that one type that can be taken to apply to all renderable objects are those filters which operate on image surfaces - ie. which are functionally equivalent to first rendering the obj to a buffer surface and then applying the filter to that (and eventually compositing the buffer surface to a dst surface). Let's agree to call such filters "surface-filters". We know several such that are commonly used - blur, bumpmap, convolution kernel derived, simple color modifiers, etc.. and one other kind that's often found are the simple 2D geometric-transform ones. We can define these from a given 3x2 matrix (normally used to define affine transformations), or more generally from a 3x3 matrix (for projective transforms of 2D space). However, given say a 3x2 matrix, one can also define geometric transformations on 'vgfx' kinds of 'objects' by operating on their vertex data, and lets call such kinds of filters "vertex-filters". If we're given a 'vgfx' kind of evas object - say a polygon or a rectangle, we may then consider 'geometric transforms' (from say a given affine 3x2 matrix) via these two different kinds of filters, the "surface" and the "vertex" ones... The results will not always be the same. Should one also consider these kinds of "vertex" filters for evas objects which have some 'vector' aspect (eg. for rect objs, or for poly objs)? And if so, how should one express these two different types of filters via the api? You might say: "No. Who cares... evas is mostly a raster based canvas lib.. or at least that's the most commonly used object - image objects..." Unfortunately, evas image objects are not really like raster surfaces at all.. in fact, they behave more like rectangles which have been given an image as a "fill pattern" (or fill texture) which is set to a repeat extend (or spread) mode by default! So, should one consider these kinds of "vertex filters" in evas, or not? I'll give you my answer to that: NO, I don't think one should. I don't think they're needed or desirable for most of the things that people want to do (but I won't go into details as to why I say that for now). PS. Here's a distantly related issue though: One of the most common things that people want to do with images is to rotate them (possibly in a 3D perspective way), flip them, blur them, etc. How can one make it easy to express such things for evas image objs (with filters) via the api? I'll give you my own partial answer to this as well - an answer that isn't really mine but rather is from a suggestion due to raster, and that is to: Add a "fill policy" flag with two possible values, say FILL_POLICY_EXTEND and FILL_POLICY_SCALE. The former (extend) is the current behavior, wherein an image is scaled to the specified fill size and then that fill extends (from the specified fill origin) to cover the image object size (repeating only for now), ie. image objects act like rectangles with the image itself as a fill pattern for the rect (the object region). The latter (scale) fill policy will ignore any "fill" properties and instead the image will be scaled to fill the image object size, ie. the image object now acts like a surface which has the image scaled to fit. This makes it very easy to deal with most uses of images where one wants to simply "transform an image in a certain way", and not worry about fill pattern sizes, transforms, extend modes, origins, and also object transforms - ie. when one wants an image obj to be like an image, not like a rect with an image as fill texture. For example, if you wanted to say "rotate an image", or just "blur an image", ... then with the current semantics of image objs you'd have several ways of setting a filter on the image obj and/or on the fill, as well as setting particular fill sizes and origins and obj sizes... all cumbersome and inefficient.. one really just wants to transform or blur the image obj and be done with it - and that's what such a new fill policy would allow.. for image objects to behave like image surfaces (subject possibly first to a scaling of the image to the object size). -
Re: [E-devel] Evas transforms/filters/etc.
> PS. > Here's a distantly related issue though: One of the most common > things that people want to do with images is to rotate them (possibly > in a 3D perspective way), flip them, blur them, etc. How can one make > it easy to express such things for evas image objs (with filters) via > the api? > > I'll give you my own partial answer to this as well - an answer > that isn't really mine but rather is from a suggestion due to raster, > and that is to: Add a "fill policy" flag with two possible values, > say FILL_POLICY_EXTEND and FILL_POLICY_SCALE. > The former (extend) is the current behavior, wherein an image > is scaled to the specified fill size and then that fill extends (from > the specified fill origin) to cover the image object size (repeating > only for now), ie. image objects act like rectangles with the image > itself as a fill pattern for the rect (the object region). > > The latter (scale) fill policy will ignore any "fill" properties > and instead the image will be scaled to fill the image object size, > ie. the image object now acts like a surface which has the image > scaled to fit. > > This makes it very easy to deal with most uses of images where > one wants to simply "transform an image in a certain way", and not > worry about fill pattern sizes, transforms, extend modes, origins, > and also object transforms - ie. when one wants an image obj to be > like an image, not like a rect with an image as fill texture. > For example, if you wanted to say "rotate an image", or just > "blur an image", ... then with the current semantics of image objs > you'd have several ways of setting a filter on the image obj and/or > on the fill, as well as setting particular fill sizes and origins > and obj sizes... all cumbersome and inefficient.. one really just > wants to transform or blur the image obj and be done with it - and > that's what such a new fill policy would allow.. for image objects > to behave like image surfaces (subject possibly first to a scaling > of the image to the object size). > I should've added that such an addition is not, strictly speaking, required... especially if one restricts filters/transforms to be of "surface" types - it'd just make things a bit simpler and more efficient for everyone. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas transforms/filters/etc.
Gustavo wrote: > On Mon, Apr 21, 2008 at 1:04 AM, Gustavo Sverzut Barbieri > <[EMAIL PROTECTED]> wrote: > >> Jose, >> >> I'm running out of time to reply to all of these ideas, I expect to >> get back some development time after the company I started start to >> calm down on the "real world side" (we were getting infrastructure and >> like, phone, network, ...). But I really fear to loose all these >> ideas. I know we have mail archive, but it would help a lot if one >> (you, others) could move this to Wiki and do some structure, much like >> Dresb and I did for some ideas. Then people can check when we're about >> to start working on it. >> >> What do you think? >> > > Ah, I'd like to write a small prototype of this idea. It would get an > ARGB buffer, get the filters as a linked list/array negotiate buffers > and then process, giving the output as another ARGB buffer to check > the results. Then modify this to add hardware accelerated surfaces > (OpenGL). Filtes would be rotation, shear and blur since they're > easier to work and can do lots of the simulation. >But if someone feels in the mood to do so before, keep me informed. > That would be a good exercise. But, don't you want to hear the rest of my philosophical commentaries? :) - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas transforms/filters/etc.
Gustavo wrote: >> > Ah, I'd like to write a small prototype of this idea. It would get an >> > ARGB buffer, get the filters as a linked list/array negotiate buffers >> > and then process, giving the output as another ARGB buffer to check >> > the results. Then modify this to add hardware accelerated surfaces >> > (OpenGL). Filtes would be rotation, shear and blur since they're >> > easier to work and can do lots of the simulation. >> >But if someone feels in the mood to do so before, keep me informed. >> > >> >> That would be a good exercise. But, don't you want to hear >> the rest of my philosophical commentaries? :) >> > > Yes I do, and actually they're very interesting at least. But I fear > I'll not have the time to go and reply them as I'd like. > Well, since you find philosophical speculations interesting, let me throw another bit of it at you before continuing with this filters stuff (mind you there are still a lot of things here that I think need to be looked into). :) We've mentioned the semantic interpretation of these 'surface' filters acting on an object as _functionally_ equivalent to first rendering the object to a buffer 'surface' and having the filter act on that surface... Ok, how about we make this former action available thru the evas api - ie. have an api func that allows for one to render an evas object to an evas image object, say of the form: void evas_object_draw(obj, dst_im_obj, x, y, w, h); or something like that. This would be an immediate-mode call, with the semantics being that the obj is drawn in its current state to the dst_im_obj's data surface, ie. composite the obj with whatever the state of the dst image surface (which can be argb data, a gl texture, an xrender pict, etc). This would open up a whole new world of immediate-mode drawing abilities to evas which haven't really been explored so far, as well as providing a user-level buffer mechanism... It can be used in many ways for many kinds of things... eg. it could be used in conjunction with smart objs with render-pre/post smart-class funcs to obtain all sorts of interesting new kinds of object types that combine elements of both immediate-mode and retained-mode gui and design/composition aspects. It can be used to cache the results of complex gfx constructs (like results of filters), to create animations that involve things like motion-blur, to And if one's clever enough, one could even find ways to add this kind of stuff to edje. PS. This is fairly easy to do right now in evas, except with the gl engine, since one'd need to draw to gl textures and there's no code in evas right now to do that. So, your work on the gl filters stuff could actually be very useful for that (among other things). PPS. You mentioned that "Filters would be rotation, shear and blur since they're easier to work and can do lots of the simulation." Ummm... rotation and shear are both just specific examples of affine transformations.. but anyway, what do you mean by 'can do lots of the simulation'? Simulation of what? - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas transforms/filters/etc.
> We've mentioned the semantic interpretation of these 'surface' > filters acting on an object as _functionally_ equivalent to first > rendering the object to a buffer 'surface' and having the filter > act on that surface... Ok, how about we make this former action > available thru the evas api - ie. have an api func that allows for > one to render an evas object to an evas image object, say of the form: > > void > evas_object_draw(obj, dst_im_obj, x, y, w, h); > > or something like that. > > This would be an immediate-mode call, with the semantics being > that the obj is drawn in its current state to the dst_im_obj's data > surface, ie. composite the obj with whatever the state of the dst > image surface (which can be argb data, a gl texture, an xrender pict, > etc). > Actually, a better form for this might be: void evas_object_draw(Evas_Object *obj, Evas_Object *im, Evas_Coord x, Evas_Coord y, Evas_Rectangle *clip); This form is useful when the src obj has a transform since the src 'origin' can be positioned at the dst image x,y coords, and the drawing restricted to the specified dst im clip region (if the clip is there, or over the whole image surface area if not). - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas transforms/filters/etc.
Gustavo wrote: >> PS. >> This is fairly easy to do right now in evas, except with the >> gl engine, since one'd need to draw to gl textures and there's no >> code in evas right now to do that. So, your work on the gl filters >> stuff could actually be very useful for that (among other things). >> > > Yes, that's something good to have and it's basically a code refactor > of the evas_render.c. As usual, I'm not sure of the impact this would > No need for much of that, though what would be best is to redo most of the image internals, and other obj rendering calls.. needs to be done anyway. > cause on NATIVE surfaces and their mixing... it would be interesting > to know the results of rendering with XRender to a GL surface, I > wonder if it's even possible. Maybe we should have a way to say "use > native" or "use software" and user would be responsible for doing > that. > > This wouldn't really have any impact with the use of 'native surfaces' - well, depends on how wide the interpretation of such. All the engines - with the singular exeption of the gl one - use native surfaces to do the rendering to, in one way or another. The update buffer images that objs are rendered to then get put on the dst display target. For the gl engine, image obj data is still held in gl textures, so one'd need to be able to render to those. Mixing gl and xrender? Well, depends how.. If you mean use gl to do filters or such, then you can get a texture from the pixmap associated with the xrender pictures that are used internally by the xrender engine to hold image data, and use gl to draw to the texture. Or do everything in software and put the result on the picture's pixmap as is now done for some things. Xrender supports projective transforms, and allows for certain filters, convolution matrices, which can even be used to, badly, mimic blurs for example. I can't begin to imagine how the idea of "rendering with xrender to a gl surface" could possibly come up.. except in a really wild interpretation of 'native surfaces'. >> PPS. >> You mentioned that "Filters would be rotation, shear and blur >> >> since they're easier to work and can do lots of the simulation." >> Ummm... rotation and shear are both just specific examples of affine >> transformations.. but anyway, what do you mean by 'can do lots of >> the simulation'? Simulation of what? >> > > simulation of cooperative and non-cooperative filters. As you said > shear and rotation could use the same affine transformation, thus > being cooperative (avoiding intermediate buffer), while shear and blur > wouldn't. We could do tests like: >- shear + rotation; >- shear + blur; >- shear + blur + rotation; > > that's lots of simulation I'm talking... sometimes I exagerate :-) > Ahhh.. Ok, I see what you mean. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas transforms/filters/etc.
I wrote: > This wouldn't really have any impact with the use of 'native > surfaces' - well, depends on how wide the interpretation of such. > All the engines - with the singular exeption of the gl one - use > native surfaces to do the rendering to, in one way or another. > That may be an exaggeration of the 'native surface' term though (for image objects). For example, the software-x11 engine *could* be thought of as having x11 pixmaps as 'native surfaces', though in fact it really uses argb buffers to render to (whose pixels are eventually put on the dst drawable thru various possible steps). It does depend on how wide one allows the interpretation of 'native surfaces - for image objects' to be.. and wether we think of them as 'native' to the (primary) rendering backend, or to the dst display target. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas transforms/filters/etc.
Carsten wrote: >> I also know that adding any of this to evas is going to >> mean a fairly large re-working of the image internals (among >> other things), and that although a general 'filters' mechanism >> is a very powerful thing, there are many, many aspects here >> that need to be considered carefully. >> > > i know. i've been thinking of this for many years now. i've known what i need > to do to make things like this work... rendering to intermediate buffers is > what is needed. i actually didnt implement in the first evas because - > pbuffers > in gl were new and not widely supported at the time and fbo/render-to-texture > didn't exist. so it got put in the "i can do it in software - but not with gl, > ok - i'll skip for now" bucket. > > True. This is something that's easy to forget. Well, this is a perfect time for those who are fans of gl (plus good gfx drivers) and want to see more support for gl in evas... to do something very useful: Modify the current gl engine to use textures as render/update (fbo) buffers.. and improve the gl engine in various other ways. :) >> Now, despite the discussions that were done at bossa, it's >> clear to me that not everyone there seems to have the same idea >> as to just what was decided - if anything. >> >> First, it seemed that 'filters' were to be a new type of >> evas object which were to be used via the current 'clipping' >> api - at least that's what I thought was being proposed, and >> you, raster, did as well. >> > > it should be LIKE the clipping api > > filt = evas_object_filter_add(); > evas_object_resize(filt, 200, 200); > evas_object_filter_effect_set(filt, EVAS_FILTER_CHILDREN_ONLY); > evas_object_filter_type_set(filt, "blur/gaussian"); > evas_object_filter_parameter_int_set(filt, "radius", 10); > evas_object_filter_add(filt, obj_to_blur); > evas_object_show(filt); > ... > > (for example - this is not fixed, but it is an IDEA). > Ok, that's certainly an interesting possibility.. except for the 'children' part - Leave the children alone! Let the parent deal with them.. ie. as is now done with other stuff: add a smart-class function to 'add' (or whatever it ends up being) the filter to the obj, and let the creators of the smart obj do whatever they want with that.. Anyway... let's see what others think. :) Also, come up with ways to add these kinds of things to edje/edc. >> Gustavo then mentioned that no, it was to be thru a similar >> mechanism, but not actually as clip objects. >> > > gustavo is right. we COULD use clip api - but i think a clip-LIKE api is > better > for filters. keep clip stuff as-is. > > One *could* of course... feel free to try and make it easy to use, consistent, unambiguous, etc... :) >> Finally, raster then further mentions something which seems >> somewhat like some other vague stuff I'd mentioned as well, but >> nothing seems particularly clear either. >> >> No mention is made of any real api for defining these 'filters' >> or how to deal with a variety of things like image-fills/borders, >> or with smart objects (apart from a vague remark about adjoining >> parent filters to members), or how to best implement any of this >> with the various engines (apart from some vague remarks about >> gl shaders and a gallium3d lib), or how to represent these things >> for use with things like edje, etc... >> > > engines will need to be able to render to a buffer. they will need to be able > to process that buffer with an algorithm. if the engine cannot do it itself, > it > can inherit from the software engine and the filter and all rendering to the > buffer will be in software - thus the filter works, just more slowly. shaders > in gl can accomplish this processing (when taking the buffer and rendering it > to its parent - ie the canvas or another buffer). > Needs some work to various internals to make it easy to 'fall-back' to software for various things (not just filters). - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas transforms/filters/etc.
Ok, let me give you some 'criticisms' I have of parts of the approaches to this filters stuff that both Carsten and Gustavo suggested, and let me start with: I just don't see a realistic "need" for having a built-in mechanism of arbitrary lists of arbitrary filters to be applied to any evas obj (or the rendering of such an obj), or as a canvas modifier object itself. I wish someone would point out an interesting, and/or common, real-time gui use of something besides: one specialty filter (say a blur or a bumpmap) followed by a geometric transform (and possibly all clipped by a mask). Anything more involved than that I'd say should be left to immediate-mode mechanisms for people to compose things as they wish (working with image objs), ie. draw the obj to an image obj and proceed to work with such.. use whatever eventual im obj to represent whatever bizarre, complex, slowly-arrived-at result you wanted.. I doubt one'd be going thru these steps all the time, so might as well create what complex effect you want and save it as an image obj for your actual real-time use (and any animations on this kind of thing you'd probably want to do apart from that, ie. on that result). - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas transforms/filters/etc.
Let me give some further thoughts on your proposed api: > it should be LIKE the clipping api > > filt = evas_object_filter_add(); > evas_object_resize(filt, 200, 200); > evas_object_filter_effect_set(filt, EVAS_FILTER_CHILDREN_ONLY); > evas_object_filter_type_set(filt, "blur/gaussian"); > evas_object_filter_parameter_int_set(filt, "radius", 10); > evas_object_filter_add(filt, obj_to_blur); > evas_object_show(filt); > ... > > (for example - this is not fixed, but it is an IDEA). > This has some interesting possibilities: 1. Since filters are new types of objs, they can be used to affect the canvas (as mentioned in before), as well as modifiers of objs. 2. If filters are allowed to 'filter' other filters, then one could replace your proposed function: evas_object_filter_add(filt, obj_to_filter); with one to just 'set' a filter: evas_object_filter_set(filt, obj_to_filter); and thus one could start by supporting one filter on an obj (so that filtering a filter would be disabled), and if deemed necessary could later allow for the general case. 3. The type/params method for specifying filters/properties is good for things like loadable filters, and one could have a "gl-shader" type with a string param named "program" which would accept the program defining the thing, and others for specifying values of variables. It might also be desirable to have some 'built-in' filters though which would not need to go thru the generic api above. There's one thing about this approach to filters as objs, namely the issue of things like the pos on the canvas of the filter object and its relation to the effect on the obj the filter is set on -- assuming such a thing as a filter's pos/size makes sense at all (eg. as if applied to the subimage defined by the pos/size of the filter?). This could have semantic issues with filters set on different objs, ie. if filters have absolute pos rel to the canvas when they are set on objs. In paticular since I believe an immediate mode 'obj-draw' func is important, I wonder if maybe filters set on an obj should have that its pos is interpreted rel to the target obj (instead of the canvas). Alternatively, assuming pos/size makes sense for a given filter, filters set on an obj could be taken as always 'at' the obj's origin, and of size equal to the obj's.. or some mixture of the two.. or what? Is it worth it to consider such things as the size and pos of a filter 'set' on an object? - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas transforms/filters/etc.
Gustavo wrote: > On Thu, Apr 24, 2008 at 3:54 PM, Jose Gonzalez <[EMAIL PROTECTED]> wrote: > >> Ok, let me give you some 'criticisms' I have of parts of the >> approaches to this filters stuff that both Carsten and Gustavo >> suggested, and let me start with: >> >> I just don't see a realistic "need" for having a built-in >> mechanism of arbitrary lists of arbitrary filters to be applied >> to any evas obj (or the rendering of such an obj), or as a canvas >> modifier object itself. >> >> I wish someone would point out an interesting, and/or common, >> real-time gui use of something besides: one specialty filter (say a >> blur or a bumpmap) followed by a geometric transform (and possibly >> all clipped by a mask). >> > > in order to do cover flow-like we need: >1 - projection; >2 - mirror; >3 - blur the mirror; > > That's one way, though in fact projection and mirror are expressible as one transform. The simplest way to do this is to perform the required transform and mask with a suitable gardient- like image (could also be defined as a single especialty filter). Would you like me to send you some simple software-based examples of how you can do this? - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas transforms/filters/etc.
>> I wish someone would point out an interesting, and/or common, >> real-time gui use of something besides: one specialty filter (say a >> blur or a bumpmap) followed by a geometric transform (and possibly >> all clipped by a mask). >> > > in order to do cover flow-like we need: >1 - projection; >2 - mirror; >3 - blur the mirror; > Also, if you did want to go thru a 'blur', you'd probably want to do this first... depends on just what effect you want to achieve. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas transforms/filters/etc.
I wrote: >>> I wish someone would point out an interesting, and/or common, >>> real-time gui use of something besides: one specialty filter (say a >>> blur or a bumpmap) followed by a geometric transform (and possibly >>> all clipped by a mask). >>> >>> >> in order to do cover flow-like we need: >>1 - projection; >>2 - mirror; >>3 - blur the mirror; >> >> >> > > That's one way, though in fact projection and mirror are > expressible as one transform. The simplest way to do this is to > perform the required transform and mask with a suitable gardient- > like image (could also be defined as a single especialty filter). > Would you like me to send you some simple software-based > examples of how you can do this? > > BTW, I should've mentioned that not only with software, but also with xrender, there are two basic, simple ways of obtaining this for 2d images using projective transforms and masks: 1. You can create a suitable gradient-like 'fade' alpha-image to use as a mask, and you can either first suitably mask the given image surface (possibly scaling the mask to 'fit' the image correctly) to a buffer image, and then use a projective transform (one which mimics a rotation around the y axis, and inverts it) on that resulting buffer image. 2. Or you can do it in one pass (no buffer images) by simultaneously transforming the given image (with the y-rotation&inversion transform) and mask with the fade using a similar transform (with possibly also does scaling, as well as y-rotating and maybe inverts too, depends on how you take the fade mask to be). There are other ways.. ones that are combos of these two, and other specialty ones if you have more to work with.. But again, it's a fairly simple thing to do with just one transform on the image and a 'fade' alpha-mask image (or gradient) which may also have a transform. With a 2d vgfx based api, it's a bit more tricky and you'd still need support for projective transforms of images from that api or specialty image filters in some way - which not all 2d vgfx apis have. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Evas object modules
Just as a change of pace from the evas filters/transforms stuff... here's a simple ability that could be useful in evas right now. There are many, many kinds of custom evas object types one could define... and some of these might involve using external libs (either in their implementation, or just by allowing one to directly use external apis). For these kinds of objects, one would not want evas to have a hard dependency on those libs, or even have such objects be necessarily compiled in. One could do some of this via smart objs (possibly extended versions thereof) and native surfaces, but even with that in place one may not want to implement things that way for efficiency and other reasons. So, one may want to be able to have a simple way to define and add new object types to evas which are optionally compiled, possibly run-time loadable, have their api in a separate header from the main Evas.h, and yet have these objs be able to take advantage of evas internals, as well as use external libs as need be. Examples of these kinds of evas objects might be a "cairo" object, an "svg" object, a set of various vgfx kinds of objects, various raster-image related kinds of objects, and even things like a full 3d-scene kind of object. There's a very simple way to have this ability in evas right, one that requires very few internal additions and no modifications to any of the current stuff. Is this something people think would be useful for evas? - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] patch: Evas fill policies
> As we discussed at IRC, probably this policies can be handled on top
> of currently existing Size_Hints and no other members should be added
> to the struct.
>
> Also agreed at IRC is that most difficult part is to get all the
> requirements written, we should start with V/HBox as they're useful
> and easier to write. We'll do this in wiki (with you sending the URL
> as soon as you get it started!).
>
> We need to figure out what hints to use, if they will be enforced or
> not or depends (configurable) and how to act when layout object
> (parent) geometry is larger or smaller than the requested/possible by
> the children and also the same about children within space when in
> homogeneous mode. A list would be:
>
> Hints to use (first draft):
>- min = max = request => no expand/fill
>- max = request = infinite => expand
>- max = infinite => fill (?)
>- maybe add more values for aspect_mode?
>
> How to lay out children within the self geometry:
> - {v,h}align from 0.0 - 1.0 to align the box composed of all
> children objects and spacing/margins. If children+spacing box is
> larger than current geometry it would overflow to the other side.
> ie: halign = 0.0 (left) would overflow to the right.
> - maybe consider -1.0 a value to "spread" (like text's
> "justify")? in the case of children+spacing not fit self geometry,
> don't overflow at either side, have them to overlap if required?
> - Other requirements?
>
> Homogeneous setups: this case is much like the reduction of the "how
> to lay out children within the self geometry" with one child. That is,
> the area to allocate for the child is what "self geometry" used to be.
> In this case we might have {v,h}align for each object as well?
>
> e17/apps/e/src/bin/e_box.c does most of that like I proposed, but it
> doesn't use any size_hints, as it was not available at the time.
>
>
> This also helps to see that it's usual to have [vh]align property.
> Edje uses this for every part, layout will use it. Maybe these
> should go as a hint in Evas_Object? Won't it be an impact on memory
> usage adding 2 double per object? let's remember many objects (ie
> clippers) will not use it. Also, I'm planing to move the size hints
> struct out of Evas_Object and have a pointer to it that would be lazy
> allocated when user set the value. If [vh]align would be desired in
> Evas_Object but the problem is struct size, this might help.
>
One of the things I see going on with this kind of thing is
an attempt to put more and more 'widgetry/layout' kinds of needs
into evas objects in a generic way. The 'problem' with some of this
is that evas objects don't have any real notion of 'inheritance' or
other sub-typing mechanism, and putting more and more of this into
evas in a generic way, though it's useful for many, many kinds of
things, also presents a potential source of 'issues', confusion,
conflicts, etc.
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas object modules
I wrote: > There's a very simple way to have this ability in evas right, > one that requires very few internal additions and no modifications > to any of the current stuff. > That should've read "...to have this ability in evas right now," Note that this deosn't mean that implementing any particular new obj type would be easy (some may, most won't), just that there'd be an simple mechanism for adding such new object types, ie. of extending evas in this way. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] patch: Evas fill policies
Gustavo wrote: >> One of the things I see going on with this kind of thing is >> an attempt to put more and more 'widgetry/layout' kinds of needs >> into evas objects in a generic way. The 'problem' with some of this >> is that evas objects don't have any real notion of 'inheritance' or >> other sub-typing mechanism, and putting more and more of this into >> evas in a generic way, though it's useful for many, many kinds of >> things, also presents a potential source of 'issues', confusion, >> conflicts, etc. >> > > Just to make clear: what goes into Evas_Object is the hints. They > could be represented as allocated structs managed with > evas_object_data_*(), but since they're so common we could 1) make it > more standard, helping integration and 2) minor optimizations by not > walking the linked list doing strcmp() in order to find these values. > The integration idea came out after the layout stuff appeared and it > would duplicate lots of stuff into edje, thus having this would help. > > All this layout stuff will not go inside evas, but some other library, > either a new one or esmart. > > Also, layout is not widgets, but they can be used to provide widgets. > They're regular smart objects that will be provided to avoid code > duplication and help integration. Also, by making it like that and > using standard properties (size hints) we can expose it from Edje > without much trouble. The big picture is to have this and enable > toolkit integration one day, like be able to mix in the same vertical > list a rectangle, an etk button and a ewl list, this would be really > easy since these (in THEORY!) should expose Evas_Object with all the > properties set. > > I understand all this, just mentioning that it may be a good idea to consider the effects of constantly adding more and more stuff into "evas objects" which have no real typing mechanism except a vey primitive one. Smart objects themselves are not done in a very good way right now - they're very, very useful and whatnot, but could've and probably should be implemented differently.. especially at the canvas level. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] More aggressive packing of Evas_Object
Gustavo wrote:
> Hi guys,
>
> As you can see from CVS log, I did some repacking of Evas_Object and
> managed to save more than 80 bytes, almost 1/3 of it is gone.
>
> While some aggressive packing went in, like "layer" number being a
> short now, I'm a bit unsure if applying the attached patch is a good
> thing. It will save 4 bytes from cur,prev, so it's 8 bytes in the end,
> but the solution is a bit ugly, as the members
> cache.clip.{visible,dirty} now are cache_clip_{visible,dirty} so it
> can be packed with the other bitfields. On one hand it saves memory,
> on the other it's ugly as hell :-P
>
> Apply or not? that's the question...
>
Hey man, I hope you didn't think my remarks about adding
properties and such had to do with object sizes... It was more
about having all these things (including some older stuff) that
may or may not apply to this or that obj type, no way to know,
etc. Ideally a "pie in the sky" kind of thing would be an evas
based on an ecore_object 'object' system (with all the ecore gui
stuff, including ecore_evas, split off from an ecore base), and
similar utopian ideals. :)
Anyway... although I'm not sure just how 'important' it is
(in practice) to have object sizes cut down as much as you managed,
that's nice work anyhow! But yeah, some of it is a bit 'ugly'...
maybe leave those parts alone?
BTW, did you kill Kenny with all that chopping away?
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] More aggressive packing of Evas_Object
Gustavo wrote: >> It was more >> about having all these things (including some older stuff) that >> may or may not apply to this or that obj type, no way to know, >> etc. Ideally a "pie in the sky" kind of thing would be an evas >> based on an ecore_object 'object' system (with all the ecore gui >> stuff, including ecore_evas, split off from an ecore base), and >> similar utopian ideals. :) >> > > I think that's overkill at this level. This is better if you take > widgets and like, so can be done in an upper level like ETK or EWL do. > I'd have to disagree with this. Even if it's just for "toolkit" use that one is concerned with, it would be very useful for some toolkits to have evas objects as part of the same object system as the widgets, some may even build the widgets by extending evas objects if they wished, or extending the base object that evas objects also extend, etc. But just in evas itself this would be extremely useful - many reasons for that. > About this I'm particular biased _AGAINST_ ecore_object. It's better > to rely on existing machinery, either "native" going C++ or > Objective-C, or going with GObject or PyObject, saving efforts to > create yet-another-poor-implemented object system in C. > > Ok, now there you're going to have political as well as logical 'issues' with various people. :) I think an ecore_object 'object' system upon which to build things like evas,edje,toolkits,... would be very useful. Even if you wanted to use gobject you could still have ecore_object built on top of it, but then you might as well replace most of ecore with glib and relatives... and this is going to be a 'political' issue with some people here. As far as using other higher-level libs, c++,obj-c,c#,java,... well, I'm sure you'll have some nice debates with people as to why and why-not one or the other. :) >> Anyway... although I'm not sure just how 'important' it is >> (in practice) to have object sizes cut down as much as you managed, >> that's nice work anyhow! But yeah, some of it is a bit 'ugly'... >> maybe leave those parts alone? >> > > the importance is that, except by image data, that's what consume most > of memory in EVAS. Also, making them smaller, consuming less cache > lines, will make applications a bit faster when you're loading batches > of them to RAM... the downside is that now comparisons will need to > apply masks before comparisons and settings, making these a bit > slower, however if you use multiple load/store of values in the same > bitfields, they can be done in one step, so a bit faster. >Also, one of the patches moved data that non-smart objects do NOT > use, and these were confusing and wasting memory. > > Some of it was nice, and the addition of the min/max values for layers was a *very* good idea (actually, something like that might be good for limits to coords and size values as well). But some of the others may just be more of a pain to deal with than any 'real' gains for practical use (that means run-time and develop-time), it depends. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas transforms/filters/etc.
Getting back to the evas filters/transforms stuff... One other aspect that needs to be addressed has to do with the very notion Gustavo mentioned about "negotiating" buffer sizes that a filter/transform might need for putting results to.. and in fact this also covers things like calculating update rects when dealing with these things at the canvas level. The problem is that it may be difficult, in general, to obtain 'bounds' for these kinds of operations on objects. Let's take the simple case of transformations. Though it's easy to deal with this for affine ones, projective ones are a bit more of a pain. There are ways to deal with this, eg. by restricting the way the transforms are obtained (say to those that are equivalent to texture-mapping a given quad), or other things, but in general it's something that poses difficulty or inefficiency. In general, the complexity and inefficiency of determining bounds or update regions increases rapidly as one allows complex filters/transforms and arbitrary chaining of these, and an object's 'geometry' no longer determines its actual drawn geometry or bounds on the canvas in a simple way. Many who use gl for rendering often don't bother with update rects, and simply re-draw the whole scene when updates are needed, or require one to manually provide the update rects. Related to this is the issue of 'picking', ie. determining whether a given canvas point lies 'over' the drawn object. This is fairly easy to deal with for transforms, affine or projective, but may also pose issues with general filters (consider one that turns an image into a blurry pretzel shape, or breaks it up into many scattered pieces all over ...). One could require that the filter provide a function to do the 'picking', but this would have to be in an inverse way, ie. from target space to source space.. and most likely would end up being a simple bounds check, which is generally very coarse. The issues here are not trivial - arbitrary filters/tranfs are difficult to deal with for ui aspects. They're fine for gfx presentations kinds of things, but not so naturally dealt with for user interfacing. These kinds of things at one point led me to consider one possibility of NOT having filters/tranfs on arbitrary objects, but rather only on objects 'bound' to a 2d-scene kind of obj. This was a fairly conservative approach, but nonetheless one that I felt should be considered... among several others. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas transforms/filters/etc.
Gustavo wrote: >> One other aspect that needs to be addressed has to do with the >> very notion Gustavo mentioned about "negotiating" buffer sizes that >> a filter/transform might need for putting results to.. and in fact >> this also covers things like calculating update rects when dealing >> with these things at the canvas level. >> The problem is that it may be difficult, in general, to obtain >> 'bounds' for these kinds of operations on objects. >> > > that's true for other parts as well, and I like raster's > simplification to "let's keep it to rectangles". Of course we could > have any shape as clip or dirty area, but it doesn't pay off. > > All in all, let's keep areas as a set of rectangles. They're easier to > operate and provide a good approximation for the first implementation. > As you said, if calculate the proper coordinates are that difficult, > then just request for whole-screen buffers and brute force :-P > It can be 'difficult' in certain ways, eg. inefficient to compute or un-intuitive results (translation before or after), etc. For affine/proj coordinate transforms one can always compute the target bounds of whatever input rect to transform (the fact is that one doesn't really transform objects, but rather coordinate systems), but some transforms make it easier to do that than others (eg. it's very easy and natural for for affine ones). And remember, these regions need to be known every time the object might need redrawing.. and it'd be good to keep update areas small if one can make use of that. :) For arbitrary filters it'll just have to be the case that the filter will need to provide a function giving such data.. though actually it's not completely clear if a surface 'filter' should require a target buffer different in size from the input surface size for its action. It very much depends on what semantics one really wants from the concept of 'surface filters'. But even if one restricts oneself to minimal bounding rects, for updates and such, there's also the issue of 'picking' to be dealt with. When it comes to that, ie. determining if a canvas point is 'inside' the (filtered/transformed) object, there are aspects that need to be decided if one wants to chain arbitrary such filters. One will at least need the filter to provide such a 'picking' function (the point to be tested against being in target space), but that won't be enough if filters are chained - one will also need the filters to provide a function to transform a given target point into a src one, or one'll have to assume the identity function by default. I imagine this kind of thing isn't done much, that most uses of surface-filters (ie. image filters) are as a means to affect image pixels only for the sake of obtaining the desired resulting effect, even if they do use coordinate transformations as well as sampling and pixel/color modifications... ie. such 'filters' are mostly interpreted as image pixel manipulation methods, not as part of a more detailed user-interface mechanism that needs explicit support for user/model coordinates. This is, in part, one reason why I think it's best to keep affine/proj coordinate transforms separate from a 'filters' notion, - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Announce] Gadman module
Andreas wrote: > The calculator works nice with edje_editor, but if I open it with > edje_viewer it doesn't work. What is the preferred way to run > "self-hosting" edje application? What's the relevant notion of: "self-hosting" edje application? > Maybe a plain C application that does > only load an edj from command line should be delivered with edje. Maybe > with options to define the backend engine. What do you think? > Besides needing to specify the display evas, one would also need to specify the group to load in the edj file. But this would hardly be enough in general to get meaningful things.. One would need to either restrict to edjes which have a certain named group (say one called 'main' or something) which is an expected wrapper for the 'edje app' and a canonical entry point to the edj file, and it would need all the 'code logic' to be done via scripting. To go beyond that, one'd need a more flexible approach.. but again, what do you want 'self-hosting edje app' to mean? - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Announce] Gadman module
Andreas wrote: >>> The calculator works nice with edje_editor, but if I open it with >>> edje_viewer it doesn't work. What is the preferred way to run >>> "self-hosting" edje application? >>> >> What's the relevant notion of: "self-hosting" edje application? >> > > My definition of "self-hosting" edje apps is an application that > doesn't need any special C code to work. See the calculator that is > referenced in the starting E-Mail from this thread. > > Then one needs to extend edje/embryo scripting far more than it's currently capable of.. and for it to be sufficiently capable for general kinds of 'apps' it may need to have access to system calls and other things. One'd also need to have well-known entry points into the .edj file - either a special main group or a special script function to execute on load or some such, and have all being executed in some kind of 'runtime'. The problem with this approach is that it doesn't provide a means to 'theme' the 'app', unless one explicitly allows for that ability as part of your notion of 'app'. Note that things like Flash/mxml (then to swf) or Silverlight/ xaml (may also have some binary representation), unlike edje/edc, have extensive 'script' language support and allow for separating the code logic from the 'gui' part in separate files if desired (though I suppose one could do this with edje/edc/embryo). One could also envision this notion in a manner similar to e17's current modules minus the configuration widgets, or like the notion of 'themable-evas-objects' I've mentioned a couple of times, ie. shared libs that have certain C function interfaces (such as 'add obj to an evas', 'set a them file on an obj', 'set,get a property/value on an obj', etc), or via scripting language modules of whatever sort. One could think of these as self-determined rather than self- hosting, and could be loaded by any program that knows the interfaces they expose. It also gives a canonical notion of 'theme' file so that one can theme these 'apps' - even though they may be self-determined, one may still want to separate the gui aspects in such a way that the 'app' can be given different gui themes. In general, there are many, many ways to imagine these kinds of notions.. but even when things start out 'self-contained', they often seem to end up wanting to become less and less so, in order to allow for more flexibility, theming, modularization, etc. >>> Maybe a plain C application that does >>> only load an edj from command line should be delivered with edje. >>> Maybe with options to define the backend engine. What do you think? >>> >>> >> Besides needing to specify the display evas, one would also need >> to specify the group to load in the edj file. But this would hardly be >> enough in general to get meaningful things.. One would need to either >> restrict to edjes which have a certain named group (say one called >> 'main' or something) which is an expected wrapper for the 'edje app' >> and a canonical entry point to the edj file, and it would need all the >> 'code logic' to be done via scripting. >> To go beyond that, one'd need a more flexible approach.. but >> again, what do you want 'self-hosting edje app' to mean? >> - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Announce] Gadman module
Gustavo wrote: >> >>> >> >> What's the relevant notion of: "self-hosting" edje application? >> >> >> > >> > My definition of "self-hosting" edje apps is an application that >> > doesn't need any special C code to work. See the calculator that is >> > referenced in the starting E-Mail from this thread. >> > >> > >> >> Then one needs to extend edje/embryo scripting far more than >> it's currently capable of.. and for it to be sufficiently capable >> for general kinds of 'apps' it may need to have access to system >> calls and other things. One'd also need to have well-known entry >> points into the .edj file - either a special main group or a special >> script function to execute on load or some such, and have all being >> executed in some kind of 'runtime'. >> >> The problem with this approach is that it doesn't provide a >> means to 'theme' the 'app', unless one explicitly allows for that >> ability as part of your notion of 'app'. >> >> Note that things like Flash/mxml (then to swf) or Silverlight/ >> xaml (may also have some binary representation), unlike edje/edc, >> have extensive 'script' language support and allow for separating >> the code logic from the 'gui' part in separate files if desired >> (though I suppose one could do this with edje/edc/embryo). >> >> One could also envision this notion in a manner similar to e17's >> current modules minus the configuration widgets, or like the notion of >> 'themable-evas-objects' I've mentioned a couple of times, ie. shared >> libs that have certain C function interfaces (such as 'add obj to an >> evas', 'set a them file on an obj', 'set,get a property/value on an >> obj', etc), or via scripting language modules of whatever sort. >> One could think of these as self-determined rather than self- >> hosting, and could be loaded by any program that knows the interfaces >> they expose. It also gives a canonical notion of 'theme' file so that >> one can theme these 'apps' - even though they may be self-determined, >> one may still want to separate the gui aspects in such a way that the >> 'app' can be given different gui themes. >> >> In general, there are many, many ways to imagine these kinds >> of notions.. but even when things start out 'self-contained', they >> often seem to end up wanting to become less and less so, in order >> to allow for more flexibility, theming, modularization, etc. >> > > Jose, > > The whole point of using Embryo instead of other VM is exactly that > you don't have any access to user's machine. I agree with that, I'd > avoid adding these calls, for such thing we can use Python or Ruby or > other scripting languages with full-system support, they have > different scope. > > Yeah, and it sounds like a fine 'security minded' approach.. but in practice it's not going to make much of a difference since edje is used along with all sorts of code that's highly insecure. What difference does it make that embryo itself can't access system calls when you have e17, e17-modules, all-sorts-of-apps/libs that use edje being written in C that can access anything and everything? Might as well have your 'scripting' language be able to do the same and restrict its use in edje itself to only 'safe' calls. The only way things will ever come close to a realistic notion of 'secure' will be when the host OS itself can be split into virtual, insulated versions of itself that are limited and private to a given user - far more than the current unix like permissions system gives. In any case, even if one wants to keep embryo to a limited VM (which is fine), there are still many ways in which its use with edje could be extended.. possibly even allowing for edje/edc and edje_cc to support other scripting languages - javascript could be good one. Alternatively, there's no need that edje should be everything to everyone, and it might be better to have other things address further needs, eg. evolve/edc for more involved widgets, maybe other animation mechanisms, etc. > I think that Andreas idea is close to mine: allow users to have nice, > beautiful toys, that are really easy to make with pure-Edje/Embryo > today, as it was demonstrated by Dave's calculator. Another examples > would be calendar viewers, little games and more... Please don't > consider these "apps" like we're used to, I don't see any need for > themes, since you just need to get another app that looks like you > want. > You may not see any need for themes now, but you/others may well see differently in time.. especially if more complex examples of such things became common. Re-usability and modularity eventually come forefront - whether it's at design/development time or at runtime.. and 'themes' are just one example of that. Replacing one 'toy' with another just to have it look somewhat differently may be fine for small toys.. but not everyone is going to limit the
Re: [E-devel] [Announce] Gadman module
Carsten wrote: >> Yeah, and it sounds like a fine 'security minded' approach.. >> but in practice it's not going to make much of a difference since >> edje is used along with all sorts of code that's highly insecure. >> > > see above. it is important. it's a mistake microsoft have made all over the > place for years and have spent years cleaning up. vb script in word documents > able to take your files and modify them or destroy them or send them to others > etc. > > What! That MS made it easy to have malware, adware, viruses, and other necessary aspects of the modern computing experience... well, that's just an eeexageration. :) Actually, the whole thing is screwed from the ground up man, there's little that can be done to have interaction with 'the world' in a rich, free, real-time sense and also be 'secure', not with the way the common, legacy systems are designed right now. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Announce] Gadman module
Then one needs to extend edje/embryo scripting far more than it's currently capable of.. and for it to be sufficiently capable for general kinds of 'apps' it may need to have access to system calls and other things. One'd also need to have well-known entry points into the .edj file - either a special main group or a special script function to execute on load or some such, and have all being executed in some kind of 'runtime'. > > i have plans to do this with edje. it'd actually be very simple. the plans go > like this: > > 1. allow edje objects to be ONLY defined by embryo script. right now you can > specify a message handling callback for an object and then script sections > when > events (programs) get triggered. there is always one on load so it's easy to > run code when the object is loaded for setup etc. etc. but i want to go > further > and add a resize() callback and a part_text_set() callback and then the code > logic here handles all of that. > 2. combined with #1 above add more hooks for the script to be able to CREATE > and > DESTROY and MANIPULATE evas objects directly. edje would track these make sure > they are cleaned up on object destruction and maybe enforce limits (like no > more > than 1000 objects or some user settable limits). > 3. add the ability to load other edje objects from the same file, so you can > mix and match the older layout and declarative way of doing objects and the > script/code way. > 4. add a few more calls like adding/deleting pollers > > It's interesting that Flash seems to have originally centered around AS, but Flex is more about a balanced combo of AS plus a declarative xml syntax and css (plus their designer/builder apps of course), and this is what most others do as well (except possibly JavaFX). Anyway... yeah, extending embryo scripting to allow for more dynamic handling of "edje/evas objects" would be very useful, but I think you're going to want the ability to 'load' objects from other edj files as well.. or at least have edje itself load such other files and let embryo functions get whatever groups/parts it needs from that file. One could argue that edje should *optionally* allow for other scripting languages (ie. optionally compiled, loadable mods), after all one could extend edje to support python or javascript in an extended edc with such added scripts.. but that would mean duplicating a lot of edje code, so why not add it as optional modules, etc. But one could instead argue that one keep whatever script/code logic separate from the initial ui/gfx description, and have the code load that external edj/eet/whatever file and work with that. But for this to work best it'd mean that the script/code would really need to go *beyond* what the edje api provides.. into the realm of what the "edje-edit" api has, so that one can dynamically create/modify/ destroy edje/evas objects (as you mentioned). In the end, I'd probably agree with this latter approach, especially for more complex stuff.. ie. separate code logic which uses other resource file(s) for its initial gfx-ui description (and it's basically what I'd meant with themable-evas-objects for C code, though it could be done with scripting too). > this should allow you to pretty much do anything that flash does with > actionscript, BUT only locally within a limited sandbox. i do NOT intend to > add > network access or any filesystem access or anything else - this is dangerous. > you download and use a theme (blindly) and suddenly it's reading your emails > and > sending them of to someone else. themes are NOT programs. they are not meant > to > be. you should not have to even think of security with them. at worst they > should just be annoying and useless. > > Note that things like Flash/mxml (then to swf) or Silverlight/ xaml (may also have some binary representation), unlike edje/edc, have extensive 'script' language support and allow for separating the code logic from the 'gui' part in separate files if desired (though I suppose one could do this with edje/edc/embryo). > > edje is not far of there. see above. it needs just a few calls and exporting > some evas and edje controls and bingo. you can do just the same. embryo is a > E... modulo some gfx bits that are still not in evas, and a fairly flexible animation framework, and video/multimedia stuff... and a browser plugin... :) >> Alternatively, there's no need that edje should be everything to >> everyone, and it might be better to have other things address further >> needs, eg. evolve/edc for more involved widgets, maybe other animation >> mechanisms, etc. >> > > it should help abstract the ui from the code. it should not become the code. > as > above. i have had plans for a long time and will get to them eventually - it's > all easy to do. i just have no NEED for it
Re: [E-devel] [Announce] Gadman module
> Note that things like Flash/mxml (then to swf) or Silverlight/ > xaml (may also have some binary representation), unlike edje/edc, > have extensive 'script' language support and allow for separating > the code logic from the 'gui' part in separate files if desired > (though I suppose one could do this with edje/edc/embryo). > > >> edje is not far of there. see above. it needs just a few calls and exporting >> some evas and edje controls and bingo. you can do just the same. embryo is a >> >> > > E... modulo some gfx bits that are still not in evas, and > a fairly flexible animation framework, and video/multimedia stuff... > and a browser plugin... :) > > > >>> Alternatively, there's no need that edje should be everything to >>> everyone, and it might be better to have other things address further >>> needs, eg. evolve/edc for more involved widgets, maybe other animation >>> mechanisms, etc. >>> >>> >> it should help abstract the ui from the code. it should not become the code. >> as >> above. i have had plans for a long time and will get to them eventually - >> it's >> all easy to do. i just have no NEED for it right now, and have other things >> to >> do, so i haven't done it. >> >> On a related note to all this, one should mention evolve/edc. There has been recent work on etk to extend the canvas widget and to allow for importing any evas object as an etk widget, with the eventual goal of allowing such notions to be representable via evolve's edc. There's also some work on a timeline based animation framework that could also be represented via evolve's edc syntax.. So, there seems to be a possible extension of edje there in some non-trivial ways. Maybe Hisham could give some further comments on what may be planned there...? - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Line + width support.
Diego wrote: > Hello all. > Working with evas+Lines in python, is fast. But if you need a line with more > then one pixel of width, it gets very slow (in dispositives like N800), > because object Line dont have width support, so its needen to use Rectangles > to make it works. > > I made a modification to support width in Lines object. It is composed by 3 > patchs. > *First*, in evas/lib/*, it changes internal call to engine line drawer, > inserting more one argument to the same function. It is a callback, so, no > modification is needen in any engine module that dosnt support Lines with > more then 1 pixel (they will just draw with only 1 pixel). Has added new > functions to deal with width, without breaking any compatibility of other > functions. > *Second*, in evas/engine/software16 to add support to width. > *Third,* in python-evas binding, to add support to use the modifications > made in evas. > > If anyone get any bug or suggest any modification to patch, im a listener. > > Thanks all > > Diego Bitencourt Contezini > This may seem like a nice addition to evas.. but it's really not a good way to go about it (nor are the particular api functions added or internal engine functions particularly desirable). Evas needs better vgfx support overall, and that means that certain kinds of objects like lines, rectangles, polygons,... should support stroke and/or fill properties - including such things as stroke weight(s) as you want here for lines. To do this correctly, and satisfactorily, needs a lot of work - something like this right now, while well-intentioned, is really not advisable.. This is not a trivial gfx aspect to support well. As far as an api goes, one should be able to set stroke and fill colors and/or textures on an object, wether an object should be stroked and/or filled (if possible), and various stroke properties such as weight(s), cap/join styles, etc. Of course one could cut down the set of things one may want evas to support - it's not necessary to have full support for everything. If you're interested in really looking into adding such vgfx capabilities to evas you could check out various polygon rasterization implementations and polygon-stroking approaches. Maybe consult with Jorge (turran) as he's been doing some work on aa polygon rasterization. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Clipped Smart Object draft
Gustavo wrote: > Anyone else looked at this? May I add the clipped smart object (no > layout stuff!) to evas? I can add some docs and even change basic > smart object to refer to this one for simple implementations. > > For those who are irc challenged, maybe you could give a short overview of what it is this is supposed to help address, why it should be 'added' to evas, etc. :) > On Mon, Mar 24, 2008 at 9:12 PM, Gustavo Sverzut Barbieri > <[EMAIL PROTECTED]> wrote: > >> http://staff.get-e.org/~barbieri/ehelpers.tar.gz >> >> This should provide what I said these days in IRC. It's a draft, for >> real code things like member_add() should check if's really a smart >> and maybe check if this Evas_Object_Smart_Clipped_Data is correct, >> maybe using an integer there with a magic number... I just left this >> out as if we use hooks then it goes away. >> >> As you can see the implementation is still generic enough and we could >> write our "layout" stuff on top of that easily, just implement the >> resize() callback to call reconfigure(), a function that would be >> called internally on child_add() and whenever things changed (ie: >> child size). >> >> If you agree with that I'll provide a layout example on top of it. >> >> - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] E CVS: libs/evas raster
+ * If the requested colorspace is the same as the image colorspace + * nothing is done and NULL is returned. + if (!o->cur.cspace == to_cspace) return NULL; To cspace or not to cspace ... - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Line + width support.
Diego wrote: > We decided to improve the line implementation to speed up the use of > evas-lines in python (our case). Yes, we could just use polygons, but we are > trying to reduce processor usage at this point. > Its faster to draw lines (with lines implementation) directly, specially > dealing with vertical/horizontal/45 deg. lines. > Calculating where points of polygons must be drawn relative to width of line > in python-side is a lost of processing too. > > Being faster, simpler and without breaking any compatibility, I dont know > why Lines should not to have width support. Specially thinking about how > simpler it makes to work with Lines. > Yes, the code may be optimized, but its working fine and fast here. > > It may be simpler to have your desired wide lines, but it's not really any faster than using current polygons, nor is it really accurate. But the real issue is simply that this is a terrible way to introduce such abilities in evas - ie. the api (and internals). As I mentioned in an earlier email, one should present this in a more general form so that further stroke/fill aspects can be exposed for not only lines but also rectangles, polygons, and maybe other objects at a later point. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Clipped Smart Object draft
>>> Anyone else looked at this? May I add the clipped smart object (no >>> layout stuff!) to evas? I can add some docs and even change basic >>> smart object to refer to this one for simple implementations. >>> >>> >> For those who are irc challenged, maybe you could give a short >> overview of what it is this is supposed to help address, why it should >> be 'added' to evas, etc. :) >> > > It's just a way to help implementation of smart objects. Most common > use smart objectcase: create an internal clipper, clip every child to > it, move will move children relatively to parent, > clip/clip_unset/color/show/hide will all go to the internal clipper. > Resize is undefined. > > What this code provide is this set of default method implementation > and an easy to extend base class, just do like in the examples and > provide your own methods (be it constructor or resize or show... you > name it), which can call the parent. I exposed all the base methods to > make it easier to use, one can override show() to do fancy stuff and > still call the original to do real work, this could be done > differently, having users to copy (ie: parent_class) Smart_Class after > evas_object_smart_clipped_smart_set() > > Why should it be added to Evas: because it's very simple, it's useful > and can serve as base for other things. > > It's definitely useful to have such a ready-made simplifying smart-class construction mechanism that could be 'overriden' - and if you could couple that with some kind of object system for smart data it might even be close to some aspects that the gui toolkits already have. ;) But I'm not sure what you're proposing about doing with it in evas itself..? Do you want to add a new 'clipped smart' object type, or do you want to re-do the current smart stuff so that they have default internal implementations for these smart functions but if the functions are user-specified, then those are used rather than the built-in default ones.. or something of that sort, or what? > Actually the idea of such component was born while I was teaching INdT > guys and after documenting that you should always do the same stuff > for most of methods I opted to add such default implementation and > errors went down by a huge factor... actually nowadays it's hard to > find a good case to use plain smart object itself. > > Al, one of things that I failed to figure in the past why show, hide, > color_set, clip_set and color_set are ALL marked as DELETE ME. I don't > remember for sure, but I think it was rephorm that did say that the > common use case is like that and maybe these methods would be replaced > with this default implementation only. So it's a good thing in that > direction. > > I've been one who's pointed out issues with these in the past as well, but the truth is that evas is not quite done with exploring those things in full and it may well be that one could want to have other implementations of such methods, or at least 'override' whatever the default ones were.. so it may not be wise to remove them altogether, no matter what jose, rephorm, raster, others may have said in the past :) - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Clipped Smart Object draft
Gustavo wrote: >> It's definitely useful to have such a ready-made simplifying >> smart-class construction mechanism that could be 'overriden' - and >> if you could couple that with some kind of object system for smart >> data it might even be close to some aspects that the gui toolkits >> already have. ;) >> >> But I'm not sure what you're proposing about doing with it in >> evas itself..? Do you want to add a new 'clipped smart' object type, >> or do you want to re-do the current smart stuff so that they have >> default internal implementations for these smart functions but if >> the functions are user-specified, then those are used rather than >> the built-in default ones.. or something of that sort, or what? >> > > just check ehelpers/evas_object_smart_clipped.[ch], they should go to > evas/src/lib/canvas (and .h to Evas.h) > > no radical change, it's just an extensible way on top of what we have > now, that I really feel is enough for our case: you can _VERY_ easily > integrate that with other object systems. I did that for Python-EFL. > No radical changes? Well that certainly puts a damper on things Gustavo.. where's the fun in that? :) Ok, I took a look at your ehelpers/evas_object_smart_clipped.[ch] and that's definitely not radical. On a more serious note: If you're not going to really extend evas per-se, just add some convenience constructs for dealing with 'common' kinds of smart objects, then why put this into evas? Why not add it to the esmart lib instead, that's a lib that's used for exactly these kinds of things (it has many useful kinds of smart classes for various things - more should be added). - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] E CVS: libs/evas raster
> > ... > >/* I TOLD YOU! this here STOPS the gradeint bugs. it's a missing > * emms() before doing floating point operations! the thread pipe code > * just brought it out reliably. i swear i had seen this long before i > * ever added the thread/pipe code. > * > * now here is why it happens. NO drawing function... EXCEPT > * evas_common_polygon_draw() and evas_common_gradient_draw() use floating > * point for drawing (the poly stuff should really lose it actually), but > * nicely nestled in the poly draw code is a evas_common_cpu_end_opt() > * before it does any operations that would use floating point. the fact > * is the gradient code was LUCKY before without the thread pipes to almost > * all the time have another func do a evas_common_cpu_end_opt() before it > * was called. that was no longer the case with the thread renderer and > * it suffered. that is why on amd systems it seemed to work as i beileve > * on amd cpu's the amms done by evas_common_cpu_end_opt() is not needed > * to do floatingpoint ops again. > * > * after a lot of futzing about - this was the culprit (well axx and axy > * were garbage values eventually i found after much debugging and i traced > * their garbageness back to here). > */ >evas_common_cpu_end_opt(); > >angle = (gr->fill.angle * M_PI) / 180.0; >axx = (cos(angle) * 65536.0); >ayy = axx; >axy = (sin(angle) * 65536.0); >ayx = -axy; > > ... > No man, you're not telling me anything I didn't already know. In fact, this is exactly what I suggested privately to Gustavo was likely happening and a possible solution to try (seems he never had a chance to try it). But it's a hack, and not really a fully thread- safe solution. And no, the gradient code wasn't "lucky" that all other funcs that use mmx were releasing those when they finish - that was the very essence of the design of the no-threads implementation.. it was *expected* that all funcs were to do that (thus, stating that it was missing an emms call "somewhere" was spacious and worthless). You should've realized that adding threads were going to break that and either fixed it, or said something to me. Instead you did nothing, said nothing, and when the bug is introduced due to your oversight, you start claiming that gradients were buggy and always rendered incorrectly and there was "nothing new".. etc. Sorry Carsten, but that was extremely bad form and unbecoming behavior on you part. Need cash? Apply now for a credit loan with fast approval. http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3m3qYuWNEnKK17HlnGL00olVgS1YmRycoonvoET3uoUOYCAQ/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/evas raster
Carsten wrote: >>> ... >>> >>>/* I TOLD YOU! this here STOPS the gradeint bugs. it's a missing >>> * emms() before doing floating point operations! the thread pipe code >>> * just brought it out reliably. i swear i had seen this long before i >>> * ever added the thread/pipe code. >>> * >>> * now here is why it happens. NO drawing function... EXCEPT >>> * evas_common_polygon_draw() and evas_common_gradient_draw() use >>> floating >>> * point for drawing (the poly stuff should really lose it actually), but >>> * nicely nestled in the poly draw code is a evas_common_cpu_end_opt() >>> * before it does any operations that would use floating point. the fact >>> * is the gradient code was LUCKY before without the thread pipes to >>> almost >>> * all the time have another func do a evas_common_cpu_end_opt() before >>> it >>> * was called. that was no longer the case with the thread renderer and >>> * it suffered. that is why on amd systems it seemed to work as i beileve >>> * on amd cpu's the amms done by evas_common_cpu_end_opt() is not needed >>> * to do floatingpoint ops again. >>> * >>> * after a lot of futzing about - this was the culprit (well axx and axy >>> * were garbage values eventually i found after much debugging and i >>> traced >>> * their garbageness back to here). >>> */ >>>evas_common_cpu_end_opt(); >>> >>>angle = (gr->fill.angle * M_PI) / 180.0; >>>axx = (cos(angle) * 65536.0); >>>ayy = axx; >>>axy = (sin(angle) * 65536.0); >>>ayx = -axy; >>> >>> ... >>> >>> >> No man, you're not telling me anything I didn't already know. >> In fact, this is exactly what I suggested privately to Gustavo was >> likely happening and a possible solution to try (seems he never had >> a chance to try it). But it's a hack, and not really a fully thread- >> safe solution. >> > > it's perfectly threadsafe. it has nothing to do with threads. it has to do > with > there being no emms called before doing fp ops. > > I don't think so. And emms isn't needed there without threads, not when all funcs clean up after themselves. Disable pipes and you don't need that. >> And no, the gradient code wasn't "lucky" that all other funcs that >> use mmx were releasing those when they finish - that was the very essence >> of the design of the no-threads implementation.. it was *expected* that >> all funcs were to do that (thus, stating that it was missing an emms call >> "somewhere" was spacious and worthless). >> > > i have seen the bug before. long ago before the thread code wen it - but it > was > rare and hard to reproduce. the thread code brought it out in some situations > to be 100% reproducable. > > You saw it in a *very* early version which called emms funcs *before* the spans were rendered. I saw it then too and shortly thereafter changed to the current version, which takes care of it - so long as we're in a non-threaded situation and all funcs (all unknown ones) which use mmx take care to clean-up, as was the design expectation. If you had told me that after adding the pipes you suddenly saw gradients completely broken, I could've helped you fix things then very quickly (it took Gustavo and I very little time, in all, to pinpoint the likely cause and possible solution). Instead, you said nothing - something which I was completely unaware of.. and when people pointed out the bug recently, you made it out like things had always been broken and that you just never cared enough to fix it. >> You should've realized that adding threads were going to break that >> and either fixed it, or said something to me. Instead you did nothing, >> said nothing, and when the bug is introduced due to your oversight, you >> start claiming that gradients were buggy and always rendered incorrectly >> and there was "nothing new".. etc. >> > > nothing to do with threads. it had to do with where in the pipeline the emms() > was called. > > >> Sorry Carsten, but that was extremely bad form and unbecoming >> behavior on you part. >> > > again. i have SEEN THIS BEFORE. BEFORE THREADS WENT IN. IT HAS BEEN THERE EVER > SINCE your fp code went in. before that gradients never used floating point. > it > has nothing to do with threads, concurrency, being thread-safe, locking (mutex > or otherwise). it has to do with there being floating point code in a pipeline > that is 99% non-floating-point. the only other instance of float stuff is in > polygons - and it is guarded correctly. the gradient code is not. > > note an emms can eat up many cycles - it used to use on the order of 140+ > cycles last i checked - but that was likely a pentium1 or penitum2. haven't > checked recently - so avoiding n emms is a good idea generally. > > again. it's a missing emms. i repeat - i have seen this bug before - long ago. > before i added thread code. it just didn't turn up very oft
Re: [E-devel] E CVS: libs/evas raster
Carsten wrote: >>> it's perfectly threadsafe. it has nothing to do with threads. it has to do >>> with there being no emms called before doing fp ops. >>> >> I don't think so. And emms isn't needed there without threads, >> not when all funcs clean up after themselves. Disable pipes and you >> don't need that. >> > > it has nothing to do with threads. i repeat. it'd threadsafe. it has to do > with > processor fp/mmx mode. each core will retain its OWN mode. threads themseleves > have nothing to do with it. > > How can they have nothing to do with it when the problem simply doesn't show up without your pipes enabled? Are saying that threads simply "bring it out..."? Bring what out, the magic juju? Sure what's happening is fp/mmx conflicts but the question is why is it happening - why doesn't it happen without pipes but does with them. If all evas internal rendering functions are releasing mmx registers correctly, then it shouldn't happen (at least) in a non- threaded situation.. and if you disable pipes I have yet to hear of an example where anyone sees it (with recent stuff). But with the pipes, the execution path seems less well-determined.. and suddenly, the problem shows up all the time. Same code, same examples - pipes disabled no problem, pipes enabled big problems. What's the reason there's a difference? Click here to find old friends, lovers or family. http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3oCe34isfl18SPSp9cXG9VOvh0IPExKyKzrJPDYmCmhtnRe4/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/evas raster
Gustavo wrote: > Ok, stop you guys! > > I cannot say for sure since I never played with mmx that much, but I > fear raster is right about that. > > as for thread safety, registers do not need special care for threads, > no locks or other requirements, so yes, it should not have any special > care. > > The issue isn't one of safety in the sense of circular referencing, it's mmx/fp 'safety', ie. that we know for certain that the execution paths aren't being interrupted in such a way that although you think you've released mmx registers, and thus the next guy is free to use fp ops.. that maybe isn't so. There is much too great a difference in the behavior of the code with vs. without pipes to say for certain that the code-execution paths are well understood. > and last but not least, actually the most important bit: gradient is fixed > now! > > Thank you both, > > No, it was more thanks to you really. Scan, remove and block Spyware. Click now! http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3mEzAoSXluEPFxkq0tJAceAQFyj1I9u6CBJpbWyR1plM6aiE/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/evas raster
Gustavo wrote: >> The issue isn't one of safety in the sense of circular >> referencing, it's mmx/fp 'safety', ie. that we know for certain >> that the execution paths aren't being interrupted in such a way >> that although you think you've released mmx registers, and thus >> the next guy is free to use fp ops.. that maybe isn't so. >> > > I believe it's up to OS to save/restore all the registers when you > change threads. Am I wrong? > > I have no idea what happens with this, or how using multiple cpu cores affects that. >> There is much too great a difference in the behavior of the >> code with vs. without pipes to say for certain that the code-execution >> paths are well understood. >> > > But do you remember my tests where I disabled the other threads, just > launching one and still having this behavior? > > As I understood you, as soon as you disabled pipes the problems disappeared - presumably mmx is being released adequately, and indeed I know of no cases where a problem has being observed (with recent cvs) without pipes or on single-core systems. And when you enable pipes again, the problem came back immediately. That's what I thought you obsrved (among other things). If that's so, then why is this ocurring.. what is the exact code path that's being executed that causes such a radical change? This needs to be understood far better than what I've seen in any remarks made by anyone so far. > Also, as I reported to you in private, the "src" was being calculated > fine, remember that I said that if I just copy the src to dst I was > getting the "correct" gradient, but of course it was not being placed > in the correct angle. > Right, because the fp calculations that gave the matrix were then junk, so the computed geometry was garbage. But the question is: Was this happening *only* when pipes are enabled, or does it happen with pipes diabled as well? I should add that: we *hope* the particular kind of bit of of 'put emms before one begins to use some sequence of fp ops' does indeed solve things in general. Save on Internet Security Hardware and Software - Click here. http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3mEWrk6AUG8nVVArr1N2uz9O46nOojLmJqilJhNinEuIxYnu/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/evas raster
Gustavo wrote: >> The issue isn't one of safety in the sense of circular >> referencing, it's mmx/fp 'safety', ie. that we know for certain >> that the execution paths aren't being interrupted in such a way >> that although you think you've released mmx registers, and thus >> the next guy is free to use fp ops.. that maybe isn't so. >> > > I believe it's up to OS to save/restore all the registers when you > change threads. Am I wrong? > > I have no idea what happens with this, or how using multiple cpu cores affects that. >> There is much too great a difference in the behavior of the >> code with vs. without pipes to say for certain that the code-execution >> paths are well understood. >> > > But do you remember my tests where I disabled the other threads, just > launching one and still having this behavior? > > As I understood you, as soon as you disabled pipes the problems disappeared - presumably mmx is being released adequately, and indeed I know of no cases where a problem has being observed (with recent cvs) without pipes or on single-core systems. And when you enable pipes again, the problem came back immediately. That's what I thought you obsrved (among other things). If that's so, then why is this ocurring.. what is the exact code path that's being executed that causes such a radical change? This needs to be understood far better than what I've seen in any remarks made by anyone so far. > Also, as I reported to you in private, the "src" was being calculated > fine, remember that I said that if I just copy the src to dst I was > getting the "correct" gradient, but of course it was not being placed > in the correct angle. > Right, because the fp calculations that gave the matrix were then junk, so the computed geometry was garbage. But the question is: Was this happening *only* when pipes are enabled, or does it happen with pipes diabled as well? I should add that: we *hope* the particular kind of bit of of 'put emms before one begins to use some sequence of fp ops' does indeed solve things in general. Looking for the perfect watch? Click now for incredible selections of designer watches. http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3mdA26SY1XfnVZtggt9xcmqPGgvECGUDdh0zmvAlRp07Brde/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/evas raster
Carsten wrote: > On Sat, 31 May 2008 13:17:42 -0400 Jose Gonzalez <[EMAIL PROTECTED]> babbled: > > >>Gustavo wrote: >> >>> I believe it's up to OS to save/restore all the registers when you >>> change threads. Am I wrong? >>> >> I have no idea what happens with this, or how using multiple cpu >> cores affects that. >> > > that was my point. it is THREAD SAFE. the os restores registers and cpu state > between context switches between threads/processes. its internal > process/threads state with the mmx/sse/fp state. the fact that pipes > restructured what gets called and how the calls get called and in what stages > they get called that brought it out reliably in certain situations. you will > find MOST of the drawing calls do NOT gaurd themselves on exit with an emms > (evas_cpu_end_opt). the only one actually was the line draw. no others do. > doing an end_opt at every draw call is not cheap - on older cpu's definitely > not. as most of evas's calls use NO floating point (and the polygon stuff > really doesn't need to - i should remove that) there is nigh zero need for > what > is a mostly useless call - and so it can go at the end of the pipeline or just > before any of the rare fp calls. again - nothing to do with threads. all to do > with streamlined rendering pipelines. > > >>>> There is much too great a difference in the behavior of the >>>> code with vs. without pipes to say for certain that the code-execution >>>> paths are well understood. >>>> >>>> >>> But do you remember my tests where I disabled the other threads, just >>> launching one and still having this behavior? >>> >>> >>> >> As I understood you, as soon as you disabled pipes the problems >> disappeared - presumably mmx is being released adequately, and indeed >> I know of no cases where a problem has being observed (with recent cvs) >> without pipes or on single-core systems. And when you enable pipes again, >> the problem came back immediately. That's what I thought you observed >> (among other things). >> > > this was my point. there has been, in the past, a case where this DOES happen. > i have seen it - but it was very rare and i didn't have any reliably > reproducable test case. the code used to do things like this > > canvas-level-render > each-object > calculate-all-things-to-draw about object and maybe call pre-render > callbacks etc. etc. (all of this may be out of evas/engine/software engine > controls) > setup draw > actually call draw call > calculate-all-things-to-draw about another object ... > setup draw > actually draw > calculate-all-things-to-draw about another object ... > setup draw > actually draw > calculate-all-things-to-draw about another object ... > setup draw > actually draw > ... > > that is how it STILL goes without the thread code enabled - the thread code > literally removes all the pipe code. that is why it goes away. the fact that > cpu control can exit the rendering pipeline into callbacks or canvas space > means that there were (almost always) guards on the fp (ie emms calls) and > thus > entering gradient drawing calls almost always worked fine. > > when there is a pipeline - even 1 single pipeline - even if i removed every > pthread call and put a pipeline "inline" it goes like: > > > canvas-level-render > each-object > calculate-all-things-to-draw about object and maybe call pre-render > callbacks etc. etc. (all of this may be out of evas/engine/software engine > controls) > setup draw > calculate-all-things-to-draw about another object ... > setup draw > calculate-all-things-to-draw about another object ... > setup draw > calculate-all-things-to-draw about another object ... > setup draw > ... > flush pipeline > draw > draw > draw > draw > ... > > and of course the flush pipeline may have multiple pipelines start their draw > cycles all at once in parallel. it splits up the destination render regions > into > N regions and each pipeline - each in its own thread, each thread is forcibly > thrust onto its own cpu/core (so threads can't migrate between cpu's/cores). > > the fact that now there was basically nothing between draw calls to guard > against fp op safety - as fp ops were not being used mostly, means that it was > much more likely u ended up with the cpu in a non emms
Re: [E-devel] E CVS: libs/evas raster
Gustavo wrote: The issue isn't one of safety in the sense of circular referencing, it's mmx/fp 'safety', ie. that we know for certain that the execution paths aren't being interrupted in such a way that although you think you've released mmx registers, and thus the next guy is free to use fp ops.. that maybe isn't so. >>> I believe it's up to OS to save/restore all the registers when you >>> change threads. Am I wrong? >>> >> I have no idea what happens with this, or how using multiple cpu >> cores affects that. >> There is much too great a difference in the behavior of the code with vs. without pipes to say for certain that the code-execution paths are well understood. >>> But do you remember my tests where I disabled the other threads, just >>> launching one and still having this behavior? >>> >> As I understood you, as soon as you disabled pipes the problems >> disappeared - presumably mmx is being released adequately, and indeed >> I know of no cases where a problem has being observed (with recent cvs) >> without pipes or on single-core systems. And when you enable pipes again, >> the problem came back immediately. That's what I thought you obsrved >> (among other things). >> If that's so, then why is this ocurring.. what is the exact code >> path that's being executed that causes such a radical change? This needs >> to be understood far better than what I've seen in any remarks made by >> anyone so far. >> > > if I force it to not use pipes, it is ok, but if I just have one > thread running (by changing code), I still have problems... so it's > not about multiple threads damaging each other... > > Ummm... Then the pipes implementation needs some inspection, because something's just not right here. That emms that raster added should not be needed - pipes or no pipes. Its presence there justs masks a serious problem, namely that something that should be releasing mmx registers either isn't doing so, or the code execution path is not allowing that to be done correctly when needed.. and this 'seems' to occur only when pipes are enabled. It's a problem that needs to be understood and fixed correctly. >>> Also, as I reported to you in private, the "src" was being calculated >>> fine, remember that I said that if I just copy the src to dst I was >>> getting the "correct" gradient, but of course it was not being placed >>> in the correct angle. >>> >> Right, because the fp calculations that gave the matrix were >> then junk, so the computed geometry was garbage. But the question is: >> Was this happening *only* when pipes are enabled, or does it happen >> with pipes diabled as well? >> >> I should add that: we *hope* the particular kind of bit of >> of 'put emms before one begins to use some sequence of fp ops' >> does indeed solve things in general. >> > > :-) > Hotel pics, info and virtual tours. Click here to book a hotel online. http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3nLmKzcX8LsMWehVLb7d1P2U2OuAHHGk1KyoF3MSkRKEaCVq/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/evas raster
I wrote: >> .. >> .. >> >> the fact that now there was basically nothing between draw calls to guard >> against fp op safety - as fp ops were not being used mostly, means that it >> was >> much more likely u ended up with the cpu in a non emms state before doing fp >> ops. even so i found it hard to reproduce in a simple test case - i needed >> the >> whole gradient dialog in e to bring it out. (i found that edje_test - the old >> one did it too eventually). my simple "display a white rectangle and a >> gradient >> on top only) test app didnt show the bug. the draw pipeline was too simple >> and >> had no mmx/sse state change before drawing the gradient - that is why. >> >> as such in the old code in some circumstances the cpu was lest in a bad fp >> state before entering the gradient draw code - but only very rarely. >> >> so i repeat - the code as such is threadsafe. mmx/sse state is separate to >> threads entirely. the only bit of code outside the gradient code that did fp >> ops was suitably guarded before doing fps ops. it's much cheaper to guard >> before the much rarer use of fps ops than guard on every exit from possible >> mmx/sse ops. >> >> >> > Let me read thru this is more detail.. But basically Carsten, > there's a problem with the pipes implementation, or they are somehow > showing a prior problem of - adequately relasing mmx. One can't > have this willy-nilly, either one can count on things to do what > they're supposed to do or fix it. You need to pass floats around, > you need to know if you can mix this func with fp ops or not, etc. > > I still haven't had a chance to go into this in detail, nor to go over some of the pipes (and other) code as I'd like.. and unfortunately I have to run away for a few days so I may not have a chance to do so for a bit... But, it's just untenable to have things in this state of affairs man - it's an undesirable source of potential bugs, inexplicable behavior, indeterminism ... One needs to be sure what the evas internal functions do or don't do, what one can count on or not, what behavior to expect, etc. One can imagine two extreme scenarios of how to deal with this: One can fix things by making sure that all mmx use in the rendering pipeline is 'cleaned-up' correctly - you can still have known routines which themselves don't clean-up, but they just have to be used only within ones which do.. and one has to make sure that always holds, regardless of the possible execution path. Or, one can modify the rendering pipeline so that one never uses any fp ops -- they would all be done in render-pre say. This might be a bit radical and difficult to realize. One must also take care to consider future extensions -- even now one can have image 'pixel' functions called, and we can't control what's being done there, even if it's outside the canvas-render func... What about if one is eventually allowed to provide a rendering function, ie. one called within the canvas render func? What should they expect.. and what should evas expect from them? Whatever the case may be, it's clear that one needs to be more careful about what's going on, and of what could go on, and that evas internals need to be more deterministic about fp/mmx, one way or another. It's also clear that you need to be bit more careful about the things you say, and your 'community' behavior in some ways. Click for online loan, fast & no lender fee, approval today http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3m3WL0hojlmOIaEdHXlXX5W7zi4gfmNJGQt15tepz7LO2utK/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] How to display a custom animated bitmap in evas/edje?
Mats Ekberg wrote: > Hi Cedric and all others. > > I have attached a minimal test case that shows the same behaviour as > our application code. The image size is set once, but the second time > (if there has been a rendering in between) the assertion error occurs > if the new size differs from the old. We are not, as Carsten Haitzler > asked, calling evas_object_image_size_set() from inside the get_pixels > callback. Perhaps there are some other restrictions on when it is > allowed to change the image size? > > /Mats > > On Wed, Jun 4, 2008 at 5:09 PM, Cedric BAIL <[EMAIL PROTECTED]> wrote: > >>> [...] when we resize it, we get the following assertion >>> error: >>> >>> evas-0.9.9.041/src/lib/cache/evas_cache_image.c:488: >>> evas_cache_image_size_set: Assertion `im->references > 0' failed. >>> >>> This does not happen the first time we set the image size, but as we >>> want the bitmap to exactly match the size of the displayed area, we >>> need to resize the buffer as the displayed area changes. Any ideas? >>> >> Sounds like a cache bug, do you have some test case for this that you >> could send to me ? >> That certainly seems odd.. any news on this? One thing I did notice while quickly looking thru the "evas_object_image.c" file in canvas was that in the render_pre function there are a couple of instances where the engines' function "image_dirty_region" is used but its return value doesn't get set to anything (according to the use it's being put to, it should be giving o->engine_data, which is the internal version of the image structure). I quickly changed that but it did nothing to fix this particular problem. There is an abundance of engine image funcs which return this. Start Email Marketing - fast, affordable, and measurable. Click here. http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3l4wZmabGD5ZyOz47O0ZKGXpVVaFDhK7yVjPERHfvpgT2CGY/ - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] How to display a custom animated bitmap in evas/edje?
Cedric wrote: > I did some test around this and I think it came from the fact that > o->dirty_pixels is not set to 1 after the second call to > evas_object_image_size_set. A quick fix for your example is to call > evas_object_image_pixels_dirty_set just after > evas_object_image_size_set. I currently don't know enough to properly > fix evas, but this could help others find the right solution. > Well, the semantics of the image-size-set function has always been that if there is no data or file for the image, it will create data of the requested size, and if there is data (possibly from a file), it will create new data of the requested size and copy as much as possible of the current data to the new one and then set that new one as the current data. So, for the test program there, after the inital rendering (of a blue area), when the resize is called the image would have new data (not the provided pixels) one pixel less in width, so the subsequent ecore induced rendering would still show the same result (even though there's no further call to 'set data' as the callback won't get triggered since 'dirty pixels' isn't called again, and it's been unset after the first rendering). This would seem to show some new problem with the 'image-resize' function when external data has been set before on the image.. and indeed if I get rid of the pixels callback and simply set the data (after the initial image size setting), then the problem is still there even without the first call to evas render.. ie. the second call to image-size-set seems to be the culprit. Click here to choose from a huge selection of shipping supplies! http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3n4Viav5LsS9677sjCU7lfWs22zXRdg638OZwylwP7y0XmIv/ - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] How to display a custom animated bitmap in evas/edje?
I wrote:
> Cedric wrote:
>
>> I did some test around this and I think it came from the fact that
>> o->dirty_pixels is not set to 1 after the second call to
>> evas_object_image_size_set. A quick fix for your example is to call
>> evas_object_image_pixels_dirty_set just after
>> evas_object_image_size_set. I currently don't know enough to properly
>> fix evas, but this could help others find the right solution.
>>
>
> Well, the semantics of the image-size-set function has always
> been that if there is no data or file for the image, it will create
> data of the requested size, and if there is data (possibly from a
> file), it will create new data of the requested size and copy as much
> as possible of the current data to the new one and then set that new
> one as the current data.
> So, for the test program there, after the inital rendering
> (of a blue area), when the resize is called the image would have
> new data (not the provided pixels) one pixel less in width, so the
> subsequent ecore induced rendering would still show the same result
> (even though there's no further call to 'set data' as the callback
> won't get triggered since 'dirty pixels' isn't called again, and
> it's been unset after the first rendering).
>
> This would seem to show some new problem with the 'image-resize'
> function when external data has been set before on the image.. and
> indeed if I get rid of the pixels callback and simply set the data
> (after the initial image size setting), then the problem is still
> there even without the first call to evas render.. ie. the second
> call to image-size-set seems to be the culprit.
>
Took a quick look at the software_generic engine, and in the file
evas_engine.c, we see the following implementations of say:
static void *
eng_image_size_set(void *data, void *image, int w, int h)
{
RGBA_Image *im;
im = image;
return evas_cache_image_size_set(image, w, h);
}
static void *
eng_image_dirty_region(void *data, void *image, int x, int y, int w, int h)
{
RGBA_Image* im = image;
if (!image) return NULL;
im = (RGBA_Image *) evas_cache_image_dirty(&im->cache_entry, x, y, w, h);
return im;
}
We may contrast these with the signatures of the called 'cache'
functions, in the evas_cache_image.c file:
EAPI Image_Entry *
evas_cache_image_size_set(Image_Entry *im, int w, int h);
EAPI Image_Entry *EAPI Image_Entry *
evas_cache_image_dirty(Image_Entry *im, int x, int y, int w, int h)
So, it may be that something's not quite correctly called here.
It's also possible that the actual implementation of the function
"evas_cache_image_size_set" isn't doing 'the right thing', but haven't
had a chance to look... Cedric?
Beauty Advice Just Got a Makeover
Read reviews about the beauty products you have always wanted to try
http://thirdpartyoffers.juno.com/TGL2141/fc/JKFkuJi7Uzun94QZstGRPRz4ClDXwJ66EmSSTAvoFpKLYfKlsEu8A4/
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] How to display a custom animated bitmap in evas/edje?
Cedric wrote:
>>> Well, the semantics of the image-size-set function has always
>>> been that if there is no data or file for the image, it will create
>>> data of the requested size, and if there is data (possibly from a
>>> file), it will create new data of the requested size and copy as much
>>> as possible of the current data to the new one and then set that new
>>> one as the current data.
>>> So, for the test program there, after the inital rendering
>>> (of a blue area), when the resize is called the image would have
>>> new data (not the provided pixels) one pixel less in width, so the
>>> subsequent ecore induced rendering would still show the same result
>>> (even though there's no further call to 'set data' as the callback
>>> won't get triggered since 'dirty pixels' isn't called again, and
>>> it's been unset after the first rendering).
>>>
>>> This would seem to show some new problem with the 'image-resize'
>>> function when external data has been set before on the image.. and
>>> indeed if I get rid of the pixels callback and simply set the data
>>> (after the initial image size setting), then the problem is still
>>> there even without the first call to evas render.. ie. the second
>>> call to image-size-set seems to be the culprit.
>>>
>>Took a quick look at the software_generic engine, and in the file
>> evas_engine.c, we see the following implementations of say:
>>
>> static void *
>> eng_image_size_set(void *data, void *image, int w, int h)
>> {
>> RGBA_Image *im;
>>
>> im = image;
>> return evas_cache_image_size_set(image, w, h);
>> }
>>
>> static void *
>> eng_image_dirty_region(void *data, void *image, int x, int y, int w, int h)
>> {
>> RGBA_Image* im = image;
>>
>> if (!image) return NULL;
>> im = (RGBA_Image *) evas_cache_image_dirty(&im->cache_entry, x, y, w, h);
>> return im;
>> }
>>
>> We may contrast these with the signatures of the called 'cache'
>> functions, in the evas_cache_image.c file:
>>
>> EAPI Image_Entry *
>> evas_cache_image_size_set(Image_Entry *im, int w, int h);
>>
>> EAPI Image_Entry *EAPI Image_Entry *
>> evas_cache_image_dirty(Image_Entry *im, int x, int y, int w, int h)
>>
>>
>> So, it may be that something's not quite correctly called here.
>> It's also possible that the actual implementation of the function
>> "evas_cache_image_size_set" isn't doing 'the right thing', but haven't
>> had a chance to look... Cedric?
>>
>
> No this is correct. But eng_image_dirty_region is not called in the
> second case. If I force the dirty_pixel to 1, it call
> eng_image_dirty_region and every thing goes ok. So perhaps in case we
> have func.get_pixels set, we should on resize set dirty_pixel to 1. I
> think this should sove the issue, but I am not sure it's really the
> correct fix.
>
Something's not correct with the image-size-set function,
it should be taking the externally set pixel data, and copying
it to newly created data and setting that as the image data.
Forget about the pixels-get function in that example, just
comment it out and instead add a call to the image-data-set func
instead... I've included a simplified version of their 'error-demo'
below which does this. It should work correctly but it doesn't.
:(
//
#include
#include
#include
#include
#define WIDTH 400
#define HEIGHT 400
Ecore_Evas *ee;
Evas *evas;
#define BUFWIDTH 10
#define BUFHEIGHT 10
static int pixels[BUFWIDTH*BUFHEIGHT]; // our buffer for the image
static void draw_to_buffer(){
int i;
// Just make the area blue
for(i=0; ihttp://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3oHgMYZMuqjBHmoQMDXxRCkTW2bKJMYk3YuHyA3lAE5qmeB5/
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
