Re: [E-devel] efl namespace
On Mon, 08 Aug 2005 14:11:14 +0200 xnowfall writes:
>
>
> Carsten Haitzler (The Rasterman) wrote:
> > On Mon, 08 Aug 2005 11:53:42 +0200 xnowfall
> <[EMAIL PROTECTED]> babbled:
> >
> >
> >>would it be possible to have the libraries use the efl:: (or some
> such)
> >>namespace? perhaps require a #define USE_EFL_NAMESPACE for
> backwards
> >>compatibility and anyone that doesn't want it?
> >
> >
> > why? they already have namespace.
> >
>
> ? you mean like the names start with ecore_ evas_ etc? well, i still
> think it would be more organized to have a namespace to contain it
> all.
> i've been wrapping stuff up in c++ where i've tried to keep similar
> names for example where efl:: would make it more clear. it's mostly
> a
> personal preference thing i guess, i tend to like to keep the
> namespace
> clean and not use a lot of using directives and so on...
>
> something like this was the idea
>
> #ifdef NAMESPACE_EFL
> namespace efl {
> #endif
>
> i was just thinking that it wouldn't change anything for those that
> don't care while still giving you the option if you want
>
>
Is that part of the C language?
---
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] the implementation of etox seems slow
On Sat, 13 Aug 2005 13:49:11 +0900 Carsten writes: > On Sat, 13 Aug 2005 00:24:25 -0400 Tianran Chen > <[EMAIL PROTECTED]> > babbled: > > > i did see the utf8 code. but utf8 is far from universal, now one > of my > > handheld computer uses alot utf16 and GB, which > evas_commont_utf8_* > > cannot handle. unicode is not yet 100% functional for CJK yet. > > the problem is - the evas api is DEFINED to accept utf8 as all > strings. all > strings are utf8 as far as it is concerned. it expects them in utf8 > and will > return them in utf8. so if you have anything that is not utf8 and > you want to > give it to evas - you must convert it to utf8 first, and vice-versa. > utf8 is > able to cover all unicode code-point space as as such so it is > sufficiently good > to do everything. :) > > > > ooh - what you may not notice is... the string is utf8... yes - > i have been > > > bad and just walked char pos's and not done proper utf8 "Walks" > when running > > > around the string (yet) i'm fixing that up - i was just getting > it working > > > with minimum hassle. i'm making it utf8 "correct". utf8 > basically means it's > > > going to handle all languages and all unicode code points - at > once. so > > > there is not much need of that :) > > > > > that's not possible as the typesetting needs a way to draw - and > that means > > > the engine layer needs to be involved as otherwise they have no > possible way > > > to draw... and if the engine layer cannot do this... you're > pretty screwed > > > :) also the fact is - i don't see a lot of typesetting engines > turning up. > > > this stuff is HARD and PAINFUL. it's not done often. > > > > hmm... i have to take a closer look at your code, i don't quite > see > > that why, but don't bother to answer me. > > trust me :) > > > > that is technically what they _layout() function does (the first > bit) - > > > until someone has another typesetting engine that would be > compatible and do > > > as much/more than the layout code... i don't see much need to > work hard on > > > this - as explained above. practically speaking it's going to be > working in > > > a void - i have no generic "typsetting api" to mimic or go by. i > have no 2nd > > > or 3rd or 4th typsetting engine to use for testing. :) > > > > fair enough. i really need vertical & right-to-left typesetter, so > if > > i can find some time during the fall semester, i will try to make > one. > > you need vertical do you? hmm - here in japan they are more than > happy to do > left to right any time. i thought it was the same in china and > korea. so i have > ignored top to bottom. i do know fo right to left issues and frankly > that is my > biggest problem at the moment. that involves having to address not > just > textblock, but evas's core text drawing routines as these ONLY draw > left to > right. i basically have not addressed right to left as i speak none > of these > langauges (arabic, hebrew etc.) and it is a bit more complex with > arabic for > example using composed characters (1 char composed of multiple > unicdoe glyphs > overlayed) and i actually don't know what it is MEANT to look like > etc. > especially mixed right to left and left to right languages - eg > quote english > within arabic sentences, or vice-versa. > You could make this work by letting such 'layout engines' use smart objects and be given as external libs, ie. libs like edje. You'd create, via the particular text format/layout lib, objects of whatever format type you want (say text/html), and when a 'string' of text is 'set' to a text-format block object, the lib would create the needed evas smart object and 'parts' which are evas text objects with text/font-face/font-size/color set on such objects as the lib choses, and with each such part giving the pos it should be rendered at. Things like underline/overstrike are extra line objects, etc. This might be a bit slow for top-bottom text and such. The best way to do this would probably be by letting such 'layout engines' be "glyph-servers", which would hand evas (from a given input string and format type) a sequence of glyph masks plus glyph geometry (leading/size/advance) plus color plus other primitive elements as needed (lines etc), where the layout engine is then responsible for obtaining the correct fonts, glyphs, etc., and also for caching these... --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] the implementation of etox seems slow
On Sat, 13 Aug 2005 02:16:49 -0400 Jose writes: > > > > You could make this work by letting such 'layout engines' > use smart objects and be given as external libs, ie. libs like edje. > You'd create, via the particular text format/layout lib, > objects > of whatever format type you want (say text/html), and when a > 'string' > of text is 'set' to a text-format block object, the lib would create > the needed evas smart object and 'parts' which are evas text objects > with text/font-face/font-size/color set on such objects as the lib > choses, > and with each such part giving the pos it should be rendered at. > Things like underline/overstrike are extra line objects, etc. > > This might be a bit slow for top-bottom text and such. > Actually evas could easily draw vertical (ie. top-bottom) text quite easily, as this merely requires advancing the 'pen' by each glyph's advance in both x and y components (same for kerning deltas) - right now it only advances the x coordinate. I haven't looked at ft2 (last ft I looked at was ft1), but it's likely that if the font is meant to be drawn vertically then ft2 will give the required glyph y advances.. In any event, font/text issues are most definately a *huge* pain, and it would require some time looking into ft2 and such in order to get a good idea of what's involved.. But for things like html, rich-text, plain-text, funky-text, etc, ... formatting schemes, it should be possible (and likely preferable) to achieve such formatting schemes with external 'smart-libs' and some modifications to evas' core glyph drawing (and possibly font/glyph caching). --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Smart objects
There are some aspects of evas' internals, particularly in relation to "smart" objects, that I'd like to expound upon here - especially since it relates to some issues I've met while recently trying to finish off some things :) In evas, the addition of "clip" objects (and possibly other kinds of 'modifier' objects, eg. filter objects, texture objects, ...), and the addition of "smart" objects, has made the internal logic of the canvas difficult to follow and control - there's too much ambiguity as to who controls what, responds to what, which functions are to be called when.., etc. In order to have an efficient rendering path, and to maintain flexibility with partly external objects like smart objects (and with modifier types of objects like clip objects), the canvas internals need to be somewhat redone. The main source of problems stems from the fact that each layer maintains a list of all objects 'in' the layer. Basically, when rendering the evas, one does something like: for each layer, one steps thru its list of objects in a 'pre-render' stage, and while doing this one builds another list of objects which is then stepped thru in a 'render' stage, and lastly one steps thru a 'post-render' stage. Objects that are 'modifier' kinds of objects, like clip objects, and objects which currently are not themselves directly 'renderable', like smart objects, have to be excluded from some of these steps - in the case of smart objects it's because currently there's nothing for them to "do" to themselves that wouldn't also involve doing things to their members.. and that's going to (possibly) get done when stepping thru the layers as we reach those member objects.. The point of the 'pre-render/post-render' stages is mainly twofold: to allow for objects to determine what parts of their state has changed since the 'last' rendering, and to allow for objects to defer expensive computations and such, until we are about to actually render the canvas.. Thus, if possible, state changes are only 'realized' internally when needed, and only those changes rel to the last time rendering occurred. In particular, this allows one to determine things like which areas need to be rendered again, rather than having to render the entire canvas each time. Currently, there's no way to have smart objects pre-render/render/post-render themselves unless we impose restrictions on the stacking order of their member objects, and/or modify the layers' object lists, and alter the rendering path somewhat. A partial step forward would be to provide smart objects with the ability to specify 'pre-render' and 'post-render' kinds of functions (eg. a 'text-formatting/layout' lib based on some smart class would have the pre-render function do something like: if object's layout state has changed, recalculate things accordingly..). Increasing the requirements on the parent/child relationship between smart objects and their members would allow for further refinements of this, and even for an (external) 'render' callback to be set on smart objects. They still cannot access rendering internals, and any internal rendering they might do on their own (by altering image data via their own resources and such), they could just as well do in the pre-render callback. What it would allow is for a generic means to handle the situation - one which would be useful to have for other types which *could* access engine internals (like evas-objects). It would allow one to define the internal default behavior of the render function for smart objects, ie. to render all their member objects (in their stacking order). It also gives a coherent semantics to the behavior of things like 'nested' smart objects, since one'd have a tree structure formed out of the parent/child relationship. Some parts of the canvas code currently "tend" towards adopting this kind of semantics, but it's not coherently applied throughout. Currently, a smart object's members can't quite make up their minds wether they belong to the smart object, or to the layer.. Right now they belong to both, in ways which vary in semantics from function to function - not altogether clearly or consistently. Let me try and give some idea of what I mean by this. Suppose you asked for the 'topmost' object in an evas, ie. called the api function "evas_object_top_get(evas)". Will you get the object which is at the top of the stacking order? eg, will you get an object that you set via "evas_object_raise(obj)" where you know that the obj belongs to the topmost layer.. Well, it depends... if the obj is a member of a smart object then you won't. What you will get is the highest object which has no 'parent', ie. is not a member of some smart object. Similar behavior obtains with other stacking-order 'get' api functions such as "evas_object_above_get". However, the related stackin
Re: [E-devel] Smart objects
On Fri, 19 Aug 2005 22:23:18 -0700 Stephen writes: > This one time, at band camp, Jose O Gonzalez wrote: > > From: Jose O Gonzalez <[EMAIL PROTECTED]> > > To: enlightenment-devel@lists.sourceforge.net > > Date: Wed, 17 Aug 2005 01:00:38 -0400 > > Subject: [E-devel] Smart objects > > > > . > > . > > . > > > > This is clearly not a well defined state of affairs -- > > either smart objects "own" their children, and/or the layer does. > > If both (so that smart objects are like disconnected > > blobs), then what is a clear, consistent semantics for stacking > > order, event handling, and associated api functions? > > > > Smart objects are just too wild.. :) > > > > > > Jose. > > I cannot believe no one has responded to this. I am not going to > pretend to have > an interesting response to this, but I can say that I did read your > whole post > and you did have some interesting things to say. Perhaps you should > stop by > #edevelop and discuss things with raster. At anyrate good stuff. > > Stephen > Carsten and I do keep in touch -- thru a secret carrier-pidgeon network :) It's just that lately he's been hit over the head with a deluge of heavyweight mail.. a lot of it from me :) One reason I wrote this is to bring the issue up and see if those who are currently using evas, and deal with these aspects, have any problems with the current semantics of the stackin order and event handling fuctions.. or not. Because one of the consequences of changing things as I'm pointing too, could be to screw up a lot of current stuff.. :( --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Smart objects
mart > object > and its member objects. > > 2nd example: > evas_object_lower(S); --> "S M1 M2 ... O" > evas_object_stack_above(O, S); --> "S O M1 M2 ..." > Now, object O is indeed above the smart object, but not above its > member > objects. > > I think the cleanest solution (and probably the easiest to implement > too) is to add two functions to smart objects: "lower_get" and > "above_get" which should respectively return the lower member object > of > the smart object and the "higher" one (I don't know if "higher" is > the > good english word: I mean the member object that is the most on the > top > of the stack). Then, when we call stack_above(obj1, obj2) or > stack_below(obj1, obj2), we check if obj2 is a smart object, and if > it > is, we call respectively obj2->above_get() and obj2->lower_get() to > know > above or below which evas object we should really stack obj1. > That's a possibility :) But there are other things involved as well, and in general the issue is really one of deciding wether or not smart objects will truly 'own' their members -- ie. wether the canvas will behave as a kind of window-system, so that the stacking order of member objects is strictly local to the parent object.. > I don't know if I've been really clear, and I've probably said wrong > things :) > > Simon TRENY > Very clear, thanks for the feedback :) jose. > > Jose O Gonzalez a écrit : > > > There are some aspects of evas' internals, particularly > >in relation to "smart" objects, that I'd like to expound upon > >here - especially since it relates to some issues I've met > >while recently trying to finish off some things :) > > > > In evas, the addition of "clip" objects (and possibly > >other kinds of 'modifier' objects, eg. filter objects, texture > >objects, ...), and the addition of "smart" objects, has made > >the internal logic of the canvas difficult to follow and > >control - there's too much ambiguity as to who controls what, > >responds to what, which functions are to be called when.., etc. > > In order to have an efficient rendering path, and to > >maintain flexibility with partly external objects like smart > >objects (and with modifier types of objects like clip objects), > >the canvas internals need to be somewhat redone. > > > > The main source of problems stems from the fact that > >each layer maintains a list of all objects 'in' the layer. > >Basically, when rendering the evas, one does something like: > >for each layer, one steps thru its list of objects in a > >'pre-render' stage, and while doing this one builds another > >list of objects which is then stepped thru in a 'render' stage, > >and lastly one steps thru a 'post-render' stage. > > Objects that are 'modifier' kinds of objects, like > >clip objects, and objects which currently are not themselves > >directly 'renderable', like smart objects, have to be excluded > >from some of these steps - in the case of smart objects it's > >because currently there's nothing for them to "do" to themselves > >that wouldn't also involve doing things to their members.. > >and that's going to (possibly) get done when stepping thru > >the layers as we reach those member objects.. > > > > The point of the 'pre-render/post-render' stages is > >mainly twofold: to allow for objects to determine what parts > >of their state has changed since the 'last' rendering, and > >to allow for objects to defer expensive computations and such, > >until we are about to actually render the canvas.. > > Thus, if possible, state changes are only 'realized' > >internally when needed, and only those changes rel to the last > >time rendering occurred. In particular, this allows one to > >determine things like which areas need to be rendered again, > >rather than having to render the entire canvas each time. > > > > Currently, there's no way to have smart objects > >pre-render/render/post-render themselves unless we impose > >restrictions on the stacking order of their member objects, > >and/or modify the layers' object lists, and alter the rendering > >path somewhat. > > A partial step forward would be to provide smart objects > >with the ability to specify 'pre-render' and 'post-render' ki
Re: [E-devel] Smart objects
On Mon, 22 Aug 2005 16:26:24 +0900 Carsten writes: > On Wed, 17 Aug 2005 01:00:38 -0400 Jose O Gonzalez > <[EMAIL PROTECTED]> babbled: > > OK man ... I am goign to TRY answer your mails... one by one... :) > That would mean that you're going to spend a week doing nothing else :) > > > > Smart objects are just too wild.. :) > > not as wild as your e-mails! :) > :) :) That's why I don't send them to the list :) Later... :) --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Smart objects
On Mon, 22 Aug 2005 12:55:48 +0200 Christian Pedaschus writes: > they're too wild for the list? now i'm really curious ;) > why don't you enlighten us all, jose? > > greets, chris > > There's little or none that I can provide, on anything.. Seek thou the being known as "the rasterman" instead :) However, there are others out there that maybe could share their thoughts on all kinds of things.. Look at things like "eterm", "evidence", "entrance", "ewl", "ecore", etc, etc,... These are truly nice works, and one can only wonder what it is that those who work on these think about them.. What capabilities would they like to add to them? How do these compare with similar others in the Gnome/Kde world? What would they like for "e" (in the larger sense) to have that they could use for advancing things? I've noticed lately the beginnings of an "exml" and an "evfs", both of which seem to me to be potentially very useful systems.. What others are there that "e" could use? Jose. --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Re: E CVS: libs/ecore sebastid
On Wed, 7 Sep 2005 11:43:59 +0900 Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]> writes: > On Tue, 06 Sep 2005 23:31:10 +0200 Kim Woelders <[EMAIL PROTECTED]> > babbled: > > > > > No. TRUE should definitely not be defined as !FALSE. > > Booleans in C are a pain. Personally, I avoid using them entirely, > as I > > think they are more trouble than helpful, when they are not > intrinsic > > to the language. > > agreed - to me it's all 1's and 0's anyway :) bool is very artifical > as it ends > up an int one way or another :) > > > How about stdbool.h, i.e. bool/true/false? I don't have much > experience > > with the portability of this one, but it's at least standardized > thing. > > > > Anyway, if nobody else is concerned, I'll just crawl back under my > rock :) > > nice rock mate! :) now where did i put mine... > > *crawls back under his rock* > Everyone should obtain at least one such rock :) In fact, this should be something available in that e-catalogue of goodies - coffee mugs, t-shirts, mouse pads, etc.. *and* a handy "e-rock" to crawl under :) jose. --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] edje and event objects
On Mon, 12 Sep 2005 14:58:51 -0500 Brian writes: > Raster, > > I've been noticing that we often want to accept generic evas mouse > events on edje objects (such as ibar icons, pager windows, pager > desks, > etc). So, we've been adding event objects and moving/resizing them > along > with the edjes and setting cb's on those. As this becomes more > frequent, > it becomes an overwhelming duplication of code, and makes things a > little tricky when stacking is involved (pager wins e.g.) > > So, I was wondering if we could wrap all this event object business > up > in evas' smart object code so we don't have to duplicate it all the > time. So, when an event cb is added to a smart object, we would > (unless > one already exists) create an event member object, and add the > events to > _that_ instead, and add the necessary hooks to keep it following the > > rest of the object properly. > > This would make smart objects behave even more seemlessly like > primitive > evas objects, and would only add the extra object overhead in the > case > where someone has actually set a cb on the smartobj (which means > they > would be adding their own event object without these changes). > > Any objections to adding this in at the evas level and saving us all > a > ton of work at the higher levels? > -- > rephorm > > This is in part one-half of the issue I tried to raise earlier in my email regarding "Smart Objects"... and it's the tougher half. One might not really 'need' to add "event objects" to a smart object - smart objects themselves could be made to "feed" events, "respond" to events, etc.. Right now, they do little of this since they are not considered to be in the list of 'event-objects' that the pointer lies in, even though they can be set, or not, to "pass" events.. a somewhat complex state of affairs. Making smart objs "own" their member objects, thus helping to solve some stacking-order issues, raises the other question: What then for event-handling? Should the current model be maintained? Or should smart objs attempt to have the same event model as say one sees in window systems? Jose. --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] edje and event objects
On Tue, 13 Sep 2005 09:18:14 -0500 Brian writes: > Jose O Gonzalez wrote: > > >On Mon, 12 Sep 2005 14:58:51 -0500 Brian writes: > > > > > >>Raster, > >> > >>I've been noticing that we often want to accept generic evas mouse > > >>events on edje objects (such as ibar icons, pager windows, pager > >>desks, > >>etc). So, we've been adding event objects and moving/resizing them > > >>along > >>with the edjes and setting cb's on those. As this becomes more > >>frequent, > >>it becomes an overwhelming duplication of code, and makes things a > > >>little tricky when stacking is involved (pager wins e.g.) > >> > >>So, I was wondering if we could wrap all this event object > business > >>up > >>in evas' smart object code so we don't have to duplicate it all > the > >>time. So, when an event cb is added to a smart object, we would > >>(unless > >>one already exists) create an event member object, and add the > >>events to > >>_that_ instead, and add the necessary hooks to keep it following > the > >> > >>rest of the object properly. > >> > >>This would make smart objects behave even more seemlessly like > >>primitive > >>evas objects, and would only add the extra object overhead in the > >>case > >>where someone has actually set a cb on the smartobj (which means > >>they > >>would be adding their own event object without these changes). > >> > >>Any objections to adding this in at the evas level and saving us > all > >>a > >>ton of work at the higher levels? > >>-- > >>rephorm > >> > >> > >> > >> > > > > This is in part one-half of the issue I tried to raise > >earlier in my email regarding "Smart Objects"... and it's the > >tougher half. > > > > One might not really 'need' to add "event objects" to > >a smart object - smart objects themselves could be made to > >"feed" events, "respond" to events, etc.. > > Right now, they do little of this since they are not > >considered to be in the list of 'event-objects' that the pointer > >lies in, even though they can be set, or not, to "pass" events.. > >a somewhat complex state of affairs. > > > > Making smart objs "own" their member objects, thus helping > >to solve some stacking-order issues, raises the other question: > >What then for event-handling? > > > > Should the current model be maintained? Or should smart > >objs attempt to have the same event model as say one sees in > >window systems? > > > > > > Jose. > > > > > I guess one possibility would be: > > When an event cb is set on a smart object: > 1) store the request callback function in the smart object > 2) set an event cb on all of the member objects with an evas > internal cb function > 3) in that internal cb function, call the callback set on the > smart obj > > That would eliminate the need for event objects, and would limit > events > to areas actually covered by a smartobj member (instead of the > entire > smartobj bounding box). > > -- > rephorm > > [BTW - recall that in general there's no constraint relating the geometry of a smart object to the visible geometrical extent of its member objects] It's a nice idea, and would likely go far to solve the problem you're facing (something like this is already done if the member objects have no callbacks set on them). But I wonder how well it will work without the smart objects also being able to "feed" events, etc.. ie, without their full support for the general event mechanisms. I believe that these kinds of issues will continue to crop up unless the underlying model around smart objects gets a clear and consistent semantics - internally, for many of the general object related functions, smart objects are functionally just 'not there'. Smart objects attempt to span a large spectrum between simple "container" or "group" like structures, and something like a full "sub-canvas" structure.. and to do so as actual canvas objects. Not an easy task. Given an evas, one can have "evas-objects", ie. an object of the given evas from which one can obtain another 'underlying' evas (one which you would not need to get/set any engine info structure) an
Re: [E-devel] edje and event objects
On Thu, 15 Sep 2005 13:02:42 +0900 Carsten writes: > On Wed, 14 Sep 2005 02:52:51 -0400 Jose O Gonzalez > <[EMAIL PROTECTED]> babbled: > > > . > > I have the feeling that unless smart-objects adopt most > > of the semantics that is used in window systems (in dealing with > > the parent/child relationship), it is likely that they will > > continue to be 'problematic' in one sense or another, for > > someone or other's needs or expectations.. :( > > indeed smart objects need work. recent ddiscussions with simon, > hisham and > brian have come to the agreement they need a reworking interllalyl - > as > discussed. putthing child objects literally as children of the smart > object. > and so on. this should solve a lot of hacks. smart object coudl do > with being > able to intercept events befotre going to a child and > transform/modify the > event, deny it going to a child or pass it through etc. we need to > take a look > at smart objects again. ,maybe we need a new kind of smart objects > that is mroe > extensive? there's a lot fo work we can do to evas. if thats all i > had on my > plate i would have done it a long time ago! :) > > unforutnately (for evas) it has reached that "it's good enough" > stage where > incentive is low compared to the priority of other work... we should > work on > this together though. i am taking notes :) > > -- Let me sharply critical here. Unfortunately for many other libs and apps, if evas is the graphics engine they use, it's important to get it more than just "good enough" -- as they will later find themselves stuck in the situation where what was good enough earlier is not quite good enough anymore.. What then? There are general patterns here, going beyond anything to do with evas in particular, that lead to such things recurring again and again... hampering the potential growth and development of "e" in the larger sense. If "e" aims to be a "gui platform" of some sort, say eg. a "desktop shell", then it needs to take a serious look at its foundations.. its subsystems... It needs to build these, and build from these, in a systematic and coherent manner... and it needs to support and facilitate all the 'standards' that people expect to have these days. Unless this is done, e will never scale much besides constituting a handful of very nice special-purpose programs like a window manager, a graphical terminal, a login manager, ... programs that, sooner rather than later, 'others' will be able to duplicate in "coolness", and do so within the context of a much more comprehensive framework. E will lead the way, in various gui related ideas, thanks mostly to the tremendous creative talents and skill of a certain nameless individual.. but it will never keep that lead for long, or be able to capitalize on it. Jose. --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] edje and event objects
On Fri, 16 Sep 2005 16:18:50 +0900 Carsten writes: > On Fri, 16 Sep 2005 01:44:42 -0400 Jose O Gonzalez > <[EMAIL PROTECTED]> babbled: > > > Let me sharply critical here. > > > > Unfortunately for many other libs and apps, if evas is the > > graphics engine they use, it's important to get it more than just > > "good enough" -- as they will later find themselves stuck in the > > situation where what was good enough earlier is not quite good > > enough anymore.. What then? > > true. but given that i only have a few hrs a week to do this stuff. > what do i > work on? e is a priority. likely above evas in priority right now. > I know.. But it's not just evas I'm trying to point to here. > > There are general patterns here, going beyond anything to > > do with evas in particular, that lead to such things recurring > > again and again... hampering the potential growth and development > > of "e" in the larger sense. > > a lot of them can be changed internally at this stage and > hidden/wrapped by > ecore_evas (ie if we move event handling to an explicit process > call). so only > those doing their own display target bindings are affected (very > few). for > smart objects i think we cna do this all internally with no api-side > effects so > we can do this at any time in the future :) i actually wouldnt mind > getting > right of the smart class creator that accepts like 10 args forall > the methods, > but instead use the one that accepts the smart as a struct - we can > then expand > that strucxt until the cows come home. it's alreayd there, just not > used. > Ok. Let's talk about canvas/gfx specific issues a bit. Two key elements: rendering and event-handling. But how do we deal with them and integrate them - what's the model? And what can we 'use' to do this? We need an immediate-mode rendering engine.. let's get it out of the canvas so it can be accessed itself. This needs a variety of other things.. including things like dealing with image loading, font loading, and others. It needs file-handling routines, string-handling routines, caching mechanisms, etc.. Where do they come from? We need a retained-mode canvas model.. What is it? There are many 'canvases' one can have, as I pointed out to you in some emails.. Which objects with what apis does one settle on? Why? Then, what is the event-model? And where does it come from? Sure we can "fix" smart-objects in evas.. But, why? What is it that you really want that smart-objects gave you initially? > > If "e" aims to be a "gui platform" of some sort, say eg. > > a "desktop shell", then it needs to take a serious look at its > > foundations.. its subsystems... > > indeed - if i had the time i'd be devoting it there. :) > That is where you are needed most man! > > It needs to build these, and build from these, in a > > systematic and coherent manner... and it needs to support > > and facilitate all the 'standards' that people expect to have > > these days. > > > > Unless this is done, e will never scale much besides > > constituting a handful of very nice special-purpose programs > > like a window manager, a graphical terminal, a login manager, > > ... programs that, sooner rather than later, 'others' will be > > able to duplicate in "coolness", and do so within the context > > of a much more comprehensive framework. > > agreed, but the programs si what peolpe seem to be wanting and > pining for. > personalyl me too. peoelp are waiting for them. wanting them. its a > 2 way > street. u cant go make a set of libs and never have anything USE > them. i agree > we need to do things. i woudl be doing them mystelf - but i don't > have time. > i'm hoping others can get a firm grip on what to do int he meantime > until i > come back to it. > They won't unless the 'core' e-developers come together and discuss design decisions, aims, etc. And you need to lead them there... > > E will lead the way, in various gui related ideas, thanks > > mostly to the tremendous creative talents and skill of a certain > > nameless individual.. but it will never keep that lead for long, > > or be able to capitalize on it. > > > > Jose. > > --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] edje and event objects
On Sat, 17 Sep 2005 13:10:27 +0900 Carsten writes: > On Fri, 16 Sep 2005 05:28:38 -0400 Jose O Gonzalez > <[EMAIL PROTECTED]> babbled: > > > Ok. Let's talk about canvas/gfx specific issues a bit. > > > > Two key elements: rendering and event-handling. But how do > > we deal with them and integrate them - what's the model? And what > > can we 'use' to do this? > > > > We need an immediate-mode rendering engine.. let's get it > > out of the canvas so it can be accessed itself. > > do we NEED it exposed at this stage? NEED is the wordd. yes it'd be > NICE, but > do we NEED to expose it. can ADD this as a feature later and EXPOSE > it later > on. ? i think we can :) > It would be very useful, for many reasons.. But no, it's not really needed at this time :) > > This needs a variety of other things.. including things > like > > dealing with image loading, font loading, and others. It needs > > file-handling routines, string-handling routines, caching > mechanisms, > > etc.. Where do they come from? > > > > We need a retained-mode canvas model.. What is it? There > are > > many 'canvases' one can have, as I pointed out to you in some > emails.. > > Which objects with what apis does one settle on? Why? > > the canvas as such already is retained-mode as all object retain > their state. > if you literally mean rendering to sub-canvases ecore_evas offers a > buffer > canvas that returns an evas object that it renders to and accepts > events on > like a child object. > Ecore-evas' "buffer" based sub-canvas is 'flawed' in several respects: 1. It forces one to use the software engine, like it or not, and with modular based engines that means loading that engine. 2. It's an inefficient use of buffering as a means to achieve 'sub-canvas' like capabilities. This can be done far more efficiently internally by fitting the sub-canvas 'buffer' to the parent engine type. 3. It could potentially introduce disimilar rendering results, or even 'features' that one engine might not support (but the software engine does, say) -- one would prefer that the parent canvas rendering and the sub-canvas rendering would match. There are a few other reasons why this is less than optimal or desirable.. But no, that's not what I meant here. There are many canvas 'models' in the object types they support and the event model they (may) use: The most common seems to be a canvas of various graphical "primitives" (lines, rects, etc), and often the evnt-model is relegated to whatever event model the underlying target surface may support. There is what we might call the w3's "svg" canvas model. This has one object type, the svg-document (or document fragment), and the event-model contains (among others) things like tracking changes in the document's structure.. There is "edje" - this is easily seen as a canvas with, again, only one object type, and 'edje' (which, like the svg- doc, is also an object loaded from from some structured file- based format). The event-model here is somewhat different from evas' own, and has things like named messages.. There others... and indeed we may even think of "ewl" as a canvas. > > Then, what is the event-model? And where does it come > from? > > same event module if its a sub-canvas as above (buffer engine) :) > > > Sure we can "fix" smart-objects in evas.. But, why? What > is > > it that you really want that smart-objects gave you initially? > > because they are a bit ugly internally. it will simplify the code a > lot and > make it easier to build on in the future. :) > You don't have to tell me that part of it :) But, again, that's not what the question is intended to address. Why do you have to have smart-objects? What is it that you want them to give you? An "edje" lib? There are better ways of getting that.. > > > > If "e" aims to be a "gui platform" of some sort, say > eg. > > > > a "desktop shell", then it needs to take a serious look at its > > > > foundations.. its subsystems... > > > > > > indeed - if i had the time i'd be devoting it there. :) > > > > > That is where you are needed most man! > > i'm needed everywhere :) > You got me there :) I will most definitely not argue with that one :) :) > > > > It needs t
Re: [E-devel] edje and event objects
On Fri, 16 Sep 2005 09:44:08 +0900 Carsten writes: > On Thu, 15 Sep 2005 19:48:31 -0400 Rodolfo Hansen <[EMAIL PROTECTED]> > babbled: > > > I'm not very familiar with how evas or smart objects are currently > > structured, > > but since you are looking for mechanisms for structured event > handling > > I was wondering if any of you have thought about using > statecharts? > > > > I work alot with statecharts in my workplace (mostly a GSM Car > alarm) > > and have been very curious about > > implementing statechart behavior in a GUI or graphics related > stuff... > > > > To be honest, I am rather interested in what people who actualy > write a > > GUI think about statecharts in general... > > if you are talking about what i think you are - thats kind of how > things work - > when u move an object evas sees if this obj intersected the poitner > xo-ord, if > it did evas tries to determine if the pointer left the object (or > entered) and > then calls the enter or leave callbacks accordingly - thus it's > handlign a > state transition as such implicitly. > U... With the current evas CVS, this will only ocurr when there's a really deep "thaw", ie. if the events_frozen count is < 0. Only then will the show, hide, move, resize,... functions actually generate a mouse_move event feed. Is that what you want? --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] edje and event objects
On Wed, 21 Sep 2005 23:57:02 +0900 Carsten writes:
> On Wed, 21 Sep 2005 01:15:46 -0400 Jose O Gonzalez
> <[EMAIL PROTECTED]> babbled:
>
> >
> >
> > On Fri, 16 Sep 2005 09:44:08 +0900 Carsten writes:
> > > when u move an object evas sees if this obj intersected the
> poitner
> > > xo-ord, if
> > > it did evas tries to determine if the pointer left the object
> (or
> > > entered) and
> > > then calls the enter or leave callbacks accordingly - thus it's
> > > handlign a
> > > state transition as such implicitly.
> > >
> >
> > U... With the current evas CVS, this will only ocurr
> when
> > there's a really deep "thaw", ie. if the events_frozen count is <
> 0.
> > Only then will the show, hide, move, resize,... functions actually
> > generate a mouse_move event feed. Is that what you want?
>
> err no - i meant that if the canvas is unfrozen (freeze==0) then if
> u
> manipulate an object (move, resize, show, hide, raise, lower etc.)
> evas sees if
> the change itnersects the pointer and if so generates an event,
> based on prev
> and current state.
Yeah.. But unfortunately the current evas in CVS does not
do that :(
Mainly (but also due to some pass-events confusion) due to
oversights wherein you have things like:
if (events_frozen != 0) { do_event_feed_stuff }
Now, these things are easy to 'patch'... But there are *dozens*
of these kinds of issues throughout the canvas code. No amount of
simple patching is going to fix the basic problems -- the canvas
code needs a complete rewrite, especially in relation to clipping,
stacking, and event-handling.
In order to do that *right*, there are design issues that
need to be addressed...
---
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] edje and event objects
On Wed, 21 Sep 2005 23:30:24 -0400 dan sinclair <[EMAIL PROTECTED]> writes: > [snip] > > the canvas > > code needs a complete rewrite, especially in relation to clipping, > > stacking, and event-handling. > > > > In order to do that *right*, there are design issues that > > need to be addressed... > > You do realize that for pretty much any software in existence a > rewrite > is the last thing you possibly want to do? Precisely why it's important to get things right as much as possible - and that takes time and thought... > You do realize that evas > is > evas2 don't you? > Yes, I'm very well aware of that. > Do you realize just how long that would take to complete? I have a pretty good idea of that, yes. Thanks for the feedback :) --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] edje and event objects
On Thu, 22 Sep 2005 12:36:22 +0900 Carsten writes:
> On Wed, 21 Sep 2005 22:34:26 -0400 Jose O Gonzalez
> <[EMAIL PROTECTED]> babbled:
>
> >
> >
> >
> > Yeah.. But unfortunately the current evas in CVS does not
> > do that :(
> > Mainly (but also due to some pass-events confusion) due to
> > oversights wherein you have things like:
> >
> > if (events_frozen != 0) { do_event_feed_stuff }
> >
> > Now, these things are easy to 'patch'... But there are
> *dozens*
> > of these kinds of issues throughout the canvas code. No amount of
> > simple patching is going to fix the basic problems -- the canvas
> > code needs a complete rewrite, especially in relation to clipping,
> > stacking, and event-handling.
>
> fixed :)
Damm! Now I have less to get hated for :)
>
> > In order to do that *right*, there are design issues that
> > need to be addressed...
>
> BUT not API issues. well not many. a very few. if the API remains
> constant we
> can chnage the underlyign code at any time. sure it can be improved.
> it is
> though fast and usable and does work - with some quirks. we can do
> thnigs like
> that later or in parallel under the covers.
>
To a degree, yeah.. But :)
---
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] A patch
Here's a large patch to finish a tiny leftover from the "events-frozen"
deal..
I've inlined the patch here as it's likely not worth attaching.
Maybe now Dan will hate me a microscopic amount less for all my
complaining :)
Jose.
*
***
Index: e17/libs/evas/src/lib/canvas/evas_object_main.c
===
RCS file:
/cvsroot/enlightenment/e17/libs/evas/src/lib/canvas/evas_object_main.c,v
retrieving revision 1.35
diff -u -r1.35 evas_object_main.c
--- e17/libs/evas/src/lib/canvas/evas_object_main.c 22 Sep 2005 02:52:53
- 1.35
+++ e17/libs/evas/src/lib/canvas/evas_object_main.c 23 Sep 2005 10:54:39
-
@@ -470,7 +470,7 @@
if (obj->layer->evas->events_frozen <= 0)
{
pass = evas_event_passes_through(obj);
- if (pass)
+ if (!pass)
was = evas_object_is_in_output_rect(obj,
obj->layer->evas->pointer.x,
obj->layer->evas->pointer.y, 1,
1);
*
***
---
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] About text format manipulation with EFL
On Wed, 5 Oct 2005 11:16:58 +0900 Carsten writes: > On Wed, 5 Oct 2005 01:00:10 +1000 David Seikel <[EMAIL PROTECTED]> > babbled: > > > On Tue, 4 Oct 2005 23:01:23 +0900 Carsten Haitzler (The Rasterman) > > <[EMAIL PROTECTED]> wrote: > > > > > if you want to let webcore do the text layout you will end up > with > > > TONNES of text objects - and having that many can possibly get > very > > > expensive speed-wise. for now - instead of rendering text, just > > > create dummy rectangle objects or ignore it and try everything > else. > > > > Oh come on raster, I thought you loved optimisation? B-) > > well evas was designed for maybe a few hundred or thousand or 2k > objects in a > canvas - NOt for 100,000's! :) that was something i assumed while > writing its > code - that object counts would be in this leage. :) > Ummm Even with lists and smart-objs as you have now, it might still not be too bad (especially with some pre/post render functions to help). Jose. PS. What he really loves is "caches". Get him started on that, and you'll hear no end on the matter :) --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] edje and event objects
On Fri, 7 Oct 2005 13:06:10 +0900 Carsten writes: > On Sat, 17 Sep 2005 04:24:29 -0400 Jose O Gonzalez > <[EMAIL PROTECTED]> babbled: > > > But no, that's not what I meant here. > > > > There are many canvas 'models' in the object types they > > support and the event model they (may) use: > > > > > > > > > > There others... and indeed we may even think of "ewl" > > as a canvas. > > indeed - it isnt "the same everywhere" its a problem - but its also > due to each > system being specific for a particular task. > But they *are* also all the "same". Fix where they agree, abstract where they differ into functional variables, and plug in this result as a particular value of these variables. What do you get? > > > > Why do you have to have smart-objects? > > because makign evas istelf govern the policy of "if u move 1 object > how do u > move a group of them) and resize is stupid. that level of complex > high-level > policy shoudl be exportable to "smart objects" they have been > overloaded a lot > of late though :) > They are 'underdetermined' in the variablity they allow. This leads to various problems, some of which have been encountered already, others are lurking there.. One such is the issue of 'coloring' a smart object, as I've mentioned to you. > > > the important stuff is rto make sute the api can be > > > expanded > > > without breaking it in the future. some things need to be put > > > off > > > (at last off > > > my own todo list) until others have been done. i have placed e17 > > > (itself) at > > > the top notch of my priority queue. i only do things directly > > > related to it > > > getting done (sanely) outside of it. > > > > > > of course if everyone else things we should abandon e17 and just > > > go back to > > > working on libs for a few years... ? who's voting for that? > > > (looking for hands going up). > > > > > > > Shame on you for taking such a cheap way out that one :) > > Truly shameful :) > > > > But hey, everyone knows that real men don't use *any* libs > > to write their code - think of how much easier and quicker you'd > > have had e17 done if you hadn't had to waste so much time writing > > all those pesky libs! > > seriously though - there is a bigger picture at stake and it RELIES > on use > getting e17 out the door - with perfect libs or not. > Agreed, agreed :) Far be it for me to urge for a *Total Rewrite* of e17... not if I value my life! :) But beware of being married to past "imperfections" :) --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] The current state of E Widget ToolKit Libraries (EWTKL)
Everyone here would do well to pay attention to what Carsten has been trying to say on this issue -- he is being very much the voice of reason and moderation. If I may add my own thoughts on this.. All progress depends very much on having "excited newcomers", some of these eventually become entrenched old-timers, and even better, re-excited old-timers. I remember reading once, long ago, an interview by an excited newcomer named Michael Jennings.. an interview he did of two, more or less, old-timers known as "raster" and "mandrake". Even the ivory towers of academic institutions know the need for new-comers, new-ideas, new-work,... even ones that may question "old ways". How is it that some "bazaars" fail to see this? Without the constant influx of new blood, and/or the willingness to "consider" new work, new ideas, new directions, etc.. there is little or no progress, there is instead stagnation and solidification. Witness the not-so-long-ago events around XFree86. It's easy for old-timers to feel 'threatened' by the new, even more so when there is overlap or competition in work.. suddenly there or not. But one must learn to overcome this and view things in a positive light instead. As Carsten has pointed out, there are many, many possibilities that can come of this.. good ones, if things are taken in a positive light. Oddly, in this ewl/etk case it seems that those in the two camps do seem to view things mostly in a positive light, and it seems to be mainly others who in fact do not even use ewl (or etk), who are acting as though they feel 'threatened' somehow. I personally do not know enough about ewl or etk to comment on any relative pluses or minuses or whatnot.. But there is one very very telling reality that anyone from "outside" first sees: If ewl is indeed the "official" gui toolkit of enlightenment, and it is the result of years of work... then how is it that none of the major programs that are associated as being "e"... actually use it? None do. This may very well have little to do with ewl, and would likely be the case if it were etk say.. It may also be a reflection on the overall state of gui-toolkit libs period.. there are changes in the air everywhere.. But regardless, it's a very visible state to 'outside' developers and even users of the programs. As to issues of "secrecy", "conspiracies", and whatnot... I personally have no idea, but if it means anything to anyone: I have, and know of, no secret conspiracies on anything. I've been trying to do some work on evas, mainly internal stuff and some extensions to add more vgfx support, and have lately come to see some things that I believe could be done better, etc. The fact is that evas is, more or less, fine for the way it is being used right now.. and if Carsten makes it even better before I do, and/or makes all I've done irreleveant or un-needed.. then so much the better as far as I'm concerned. But if any of it ever does see the light of day, and is perceived as useful, and becomes "applied", etc... it would affect etk as much as ewl, since both use the same -- evas and edje. Listen to raster. --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] The current state of E Widget ToolKit Libraries (EWTKL)
On Wed, 12 Oct 2005 11:01:15 -0400 Michael writes: > On Tuesday, 11 October 2005, at 23:33:18 (-0400), > Jose O Gonzalez wrote: > > > I remember reading once, long ago, an interview by an excited > > newcomer named Michael Jennings.. an interview he did of two, more > > or less, old-timers known as "raster" and "mandrake". > > You are mistaken. Was I a newcomer once? Yes, absolutely, though > it's been almost 10 years. But I'd been around for quite awhile by > the time mandrake showed up. > Perhaps so... I'd defer to raster and mandrake and you on that. As I *dimly* recall, this was around the time of the unveiling of e16 and eterm (my first experience with e was around e13 and I can't recall if eterm was around then), and you certainly *seemed* to come across, in that interview, as an excited newcomer -- to enlightenment. But if you were instead an *excited old-timer*, then even better :) If anyone can find a link to that interview somewhere, I'm sure everyone would find it an interesting read :) > > If ewl is indeed the "official" gui toolkit of enlightenment, and > it > > is the result of years of work... then how is it that none of the > > major programs that are associated as being "e"... actually use > it? > > None do. > > Also not true. > Ummm... that would very much depend on what one's list of *major* programs associated as being "e"... consists of. Perhaps you could give your list of such and pick out those that use ewl.. so that a more "official" ratio can be ascertained. Jose. --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] The current state of E Widget ToolKit Libraries (EWTKL)
On Fri, 14 Oct 2005 12:19:14 +0900 Carsten writes: > On Thu, 13 Oct 2005 16:51:23 -0500 Nathan Ingersoll > <[EMAIL PROTECTED]> > babbled: > > > > > Looking ahead, if Simon and Hisham are committed to working as > part of the > > team, one excellent way to extend an olive branch would be to BSD > license > > their theme. With the heavy GTK influence I can understand Simon's > > reluctance to use a different license, but that only covers the > code, not > > the theme. I did a quick port of their theme to EWL and it looked > pretty > > damn good, but there's no chance of this work going into the EWL > theme > > unless that license is changed. The way the two use edje is too > different at > > this time to make themes that can be effectively shared between > the two, but > > I don't see why some sharing can't occur at this level. ETK has > the benefit > > of using EWL code without fear of license complications, it would > be nice if > > EWL could do the same with the ETK theme. > > i do think that is a major issue. you dont license something the > same as > another project just because the other project heavily influenced > its design > and ideas and structure. license applies to COPIES, not influences, > ideas, > inspiration. it has to be pretty much a direct copy (and then a > derivative from > there). i agree that etk, being lgpl, is not productinve in terms of > it being > able to share back. i know i dont plan on even thinking of "blessing > it" even > as official competition - if there can be such a thing (you get the > idea) as > long as it's lgpl. it basically stands out as a sore thumb in cvs > and i 100% > agree with everyone (except simon) on this issue. it should be > changed just so > it can be shared - you can share themes (well take the theme and > adapt for > ewl), or you can find useful code in etk and use it in ewl, and > vice-versa. > It's odd but one begins to get the feeling that a lot of this negative reaction to etk has more to do with the licensing issue than with actual code, or antecedent discussion about issues, etc. I personally fail to understand the free-and-good-BSD vs political-and-bad-LGPL, stance of many here. The reality is that *any* recourse to a license, even a copyright, is taking a political stance - it is seeking protection through the legal framework via some scheme. To brand one such scheme as political but another as free of politics is illusory. I personally do not care much for any licensing schemes, and every piece of code I've ever put up here, meager as it's been, I've done so with no conditions whatever - I've not copyrighted anything, I've not licensed anything, I've not asked for my name to be added to any list of contributors, I've not asked for anything to be 'applied' or for 'access to cvs'... If others have the view that they would prefer their work to be protected under the legal framework afforded by use of copyright and/or a choice of license then that is something I very much respect. But villifying one license scheme as 'political' and blessing another as the one true 'apolitical' choice, is quite flawed. If indeed there are those who care about "choice" above all, then either place no constraints on your work, or allow for a choice of licensing schemes - allow for the work to be licensed under a number of licenses that are commonly used: BSD, GPL, XYZ, ... Jose. --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] The current state of E Widget ToolKit Libraries (EWTKL)
On Fri, 14 Oct 2005 03:46:45 -0400 Michael writes: > On Friday, 14 October 2005, at 12:19:14 (+0900), > Carsten Haitzler wrote: > > > so does everyone seem agreed we should try re-assign priorities to > > the mailing lists to be more "on topic" (make some announcements > and > > make an effort to redirect mails to users or web lists etc.) and > > then maybe free up some mail "bandwidth" for more discussion? > > Definitely. > > Michael > Open email discussion on a large number of areas of 'e' would be good :) Perhaps also something that other projects seem to do.. namely, pick one day a week (and a time period) for an 'irc meeting', where the more outstanding issues of the week are further gone over, etc. Jose. --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Re: License Issues
> most, so nothing lost there. > > and finally - i went with this license because frankly - i accepted > long long > long ago that peolpe will take and NOT GIVE BACK. they do it with > gpl - and > they do it in terms of download then ask for support - and support > takes time. > time costs money. thus effectively they are taking and NOT giving > back. they > will never write a single patch or a line of code. they will use it > and ask for > support/help - EVEN IF the help is IN documentation - they dont read > it. they > prefer to write an email to a developer and get a personalised > response. dont > worry about licenes - this is the WORST problem with open source. by > FAR. > companies are unlikely to just "steal". thats the view of those that > hate > anything commercial. practicality is that the companies need some > support - > will ask a bit, realise they use up your time and offer to PAY you > for it and > PAY for patches, custom code ans support BECAUSE the license is > muchmore open. > this helps you get some minimal money for your hard work - better > than $0. note > - we dont get paid ANYTHING to produce E related code. it's produced > out of > sheer love, sweat and tears. for all the students out there - this > stuff is > done in time on evenings and weekends after exhausting days of work. > year in > and year out. for peolpe with jobs personal time is precous and > worth a lot to > them personally - so in working on e we invest much of ourselves in > it. we are > a project with $0 funding. unlike many other projects of similar > visibility, no > company has stepped forward to seriously partner with us to fund its > development (thus it moves very slowly). over the years there have > been times > when me, or mandrake or mej have had paid work time to work on > things. but > those have been minimal in the scheme/lifetime of E. > > a BSD +attribution license is a way of extending an olive branch to > companies > possibly willing to put down some hard cash. we all have principles > and stick > to them like glue. i have had a few job offers before for large > sums, BUT they > would have meant an IP agreement that would mean i no longer could > work on E as > all my coding work would belong to the company. such offers i have > turned down, > even after negotiations and big carrots. if you cant, trust us that > we have the > interests of the project at heart and will maintain that, but in > doing so we > like to "bend with the wind" a bit more than most to achieve the > goal. > > so... after a bit of length there - thats the reason i have used bsd > licenses, > and almost all of the core develoeprs agree with such licenses as > being the way > to go - we may simply think alike on the topic, but that is one > thing that > definitely binds us all together. > All of this appears reasonable, and yet there are arguments that are also reasonable to the effect that license XYZ is instead a 'better' way to go. Rather than agonize over attempting to dissect the fine points of license A over license B, one can offer the option of both (if possible) as has been suggested by the poster. In particular, if BSD and LGPL are the A and B here, then why not have all "e" code covered under a choice of either - ie. a company or a distribution can use BSD or LGPL as they wish. Where is there a loss to e, or its developers, in this added extra flexibility?? Furthermore, in an attempt to better understand the possible benefits of A over B, or A and/or B, offerings.. one might want to look around and see which projects that use any such, and how they've fared. If one does this, one would tend to incline to the conclusion that those projects that use LGPL are more numerous, and have been somewhat more successful in being "adopted" than those that use BSD. For LGPL/GPL one has: the Linux kernel, all the basic GNU libs/programs, GNOME/Gtk, KDE/Qt, and a host of others... For BSD one has: the various BSD kernels, the X.org implementation of X11, enlightenment, and some others...? On Fri, 14 Oct 2005 04:15:57 -0400 Michael writes: > On Friday, 14 October 2005, at 01:17:02 (-0400), > Jose O Gonzalez wrote: > > > I personally do not care much for any licensing schemes, and every > > piece of code I've ever put up here, meager as it's been, I've done > > so with no conditions whatever .. > > Anything you write is copyrighted. Whether or not you implicitly > assign copyright to the original author(s) when you submit a patch > or > block of code is a matter of much debate. > Not
Re: [E-devel] Menu usability.
On Thu, 20 Oct 2005 22:36:59 -0700 Ben Ford writes: > David Seikel wrote: > > >Alternatively we could always have menus re arrange themselves > based > >on frequent usage. That would make everybody happy. B-) > > > > > > NO. > I disagree, that sounds like a great idea! And then maybe also a smart "paperclip" that pops up and closes unattended windows and other stuff like that.. Yeah! Jose. --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] b0rkies - a heads up
On Thu, 27 Oct 2005 00:25:12 +0900 Carsten writes: > OK everyone - developer beings and such. > > as was brought up on the mailing lists several months ago, > i have (FINALLY!) started some work on cleaning/rationalising > and improving eva's smart object code and interfaces. And there is much rejoicing! :) > my first step is to move smart object child objects within > the smart object itself - making the object struct less flat and > more tree-like. this shoudl mean some speedups too. Yes. Also, though not smart-obj related -- since clip-objs should have only *one* clipee, it would make sense to let a clipped obj 'own' its clipper as well.. ie. remove clippers from the layers as well. Also not smart obj related, but a small, easy optimization in most cases -- have an internal canvas render function of the form: Evas_List *_evas_render(Evas *evas, char return_updates); so that the api's render function which *does not* return updates, can be defined via the above -- with 'return_updates' set to 0. When this is 0-set, the _evas_render function can avoid creating the list of rect updates (that the evas_render function can't return anyway and just has to free). > i also plan on removing the need for clip/unclip, show/hide > and color_set methods so they are no longer used. > that will be step 2. And again there is much rejoicing! :) I would suggest adding render-pre and post methods though, as they could be very useful for more 'self-rendering' types of smart objs. The obj's render-pre and post functions have to be called anyway, just to recurse calling their childrens', so might as well have user provided ones in addition... Of course this could also cause all kinds of havoc... :( > step 3 will be removal of evas_smart_new() > in favor of using evas_smart_class_new() as it uses an extendible > struct interface. i have marked methods for deletion for now too > in that. Well, this will go a lng way to solve many of the major problems with these :) What about the event system? > so... that means if you have made smart objects... you will need to > do a little adapting soon. but in the long run it will make things > much simpler, cleaner and more expandable. Yes :) > i am still tossing up if the smart move method should be there, or > all child > objects should be simply placed rlative to the smart parent's origin > and thus > moved automatically, or if i should provide a default move method > that does > this for you. right now its save from destruction - but i'm tossing > up as to > the future of it. > > another thing to go soon will be the old textblock api - consider it > dead as of > today, and only hanging in evas in cvs as long as i simply dont get > around to > removing it. if you are using textblock2 - it will be RENAMED to > textblock once > this happens. this will cause a short period of breakage as things > move over, > but then transition will be finished. > > so - be warned... :) and enjoy the newness! :) > > -- > - Codito, ergo sum - "I code, therefore I am" > -- > The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] > $BMg9%B?(B > Tokyo, Japan ($BEl5~(B $BF|K\(B) > > --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] b0rkies - a heads up
On Thu, 27 Oct 2005 11:33:05 +0900 Carsten writes:
> On Wed, 26 Oct 2005 18:42:48 -0400 Jose O Gonzalez
> <[EMAIL PROTECTED]> babbled:
>
> >
> >
> > On Thu, 27 Oct 2005 00:25:12 +0900 Carsten writes:
> > > OK everyone - developer beings and such.
> > >
> > > as was brought up on the mailing lists several months ago,
> > > i have (FINALLY!) started some work on cleaning/rationalising
> > > and improving eva's smart object code and interfaces.
> >
> > And there is much rejoicing! :)
>
> :)
>
> > > my first step is to move smart object child objects within
> > > the smart object itself - making the object struct less flat and
>
> > > more tree-like. this shoudl mean some speedups too.
> >
> > Yes. Also, though not smart-obj related -- since clip-objs
> > should have only *one* clipee, it would make sense to let a
> > clipped obj 'own' its clipper as well.. ie. remove clippers from
> > the layers as well.
>
> yes - that would make sense. they even dont require any stacking
> order as a
> clip does not affect stacking (currently) :) but that may change (ie
> set the
> "merge buffer" option (which doesnt exist yet) on an object that is
> a clipper
> then all objects clipped will be first rendered into a tmp buffer
> THEN when the
> buffer is merged with the main drawn tree (or a parent buffer) is
> the clip mask
> applied. - example (as you were saying before - api-wise we are able
> to add it
> trivially. its the engine side that will have issues)
>
> what i REALLY want though is to reduce the side of clippee lists
> simple by
> havign all child objects of a smart be clipped by the clipper OF a
> smart object
> automatically :)
>
A large gain there for many reasons :)
> > Also not smart obj related, but a small, easy optimization
> > in most cases -- have an internal canvas render function of the
> > form:
> >
> > Evas_List *_evas_render(Evas *evas, char return_updates);
> >
> > so that the api's render function which *does not* return updates,
> > can be defined via the above -- with 'return_updates' set to 0.
> > When this is 0-set, the _evas_render function can avoid creating
> > the list of rect updates (that the evas_render function can't
> > return anyway and just has to free).
>
> while technically an optimisation, in practice - you will never
> measure any
> speedup as the overhead of a malloc and list append per region per
> render cycle
> is in the realm of < 0.1% of the grunt needed to render :)
>
Yeah.. But remember the old saying "...every little bit helps..."
and if it's a freebie like this one, then what the heck! :)
Also unlikely to have any affect most times, but that perhaps
could be a simplification of things:
I don't see why there's a need to build a separate list of
"restack objs" (in the render function)? This seems to be simply
something that should be done in each obj's render_pre func,
ie. like:
if (obj->changed)
{
...
if (obj->restack)
// add cur-prev updates and goto done..
...
}
> > > i also plan on removing the need for clip/unclip, show/hide
> > > and color_set methods so they are no longer used.
> > > that will be step 2.
> >
> > And again there is much rejoicing! :)
> >
> > I would suggest adding render-pre and post methods though,
> > as they could be very useful for more 'self-rendering' types of
> > smart objs. The obj's render-pre and post functions have to be
> > called anyway, just to recurse calling their childrens', so might
> > as well have user provided ones in addition...
> > Of course this could also cause all kinds of havoc... :(
>
> right now i dont plan on extending smart objects to be able to
> directly render
> (yet) as that would require exporting the immediate-mode rendering
> api to them
> - even calling the render of a sub object is not that useful as
> well- it can
> call it itself :) but the idea of the class struct is that in FUTURE
> we can add
> "render" smart calls that if set to non-NULL will allow a smart obj
> to provide
> direct rendering calls of its own - effectively becoming an extended
> object.
>
Yes.. But the idea behind render_pre and render_post functions,
for smart-objs, is to allow their designer to defer whatever expensive
calculations til render time, ie. so they can also have the ability
to keep
Re: [E-devel] Stuff
On Sat, 26 Nov 2005 16:04:03 +0100 Massimo Maiurana <[EMAIL PROTECTED]> writes: > Jose O Gonzalez, il 26/11/2005 13:42, scrisse: > > > > Just some attached evas stuff for raster's amusement :) > > AARRGGHH! > > an 500KB attachment now that my isp is on low bamdwidth :(( > Yes, my apologies.. though it was 372KB on my disk, it's still quite large. Sending diffs though may end up being larger. I'll see if I can find a better way. Jose. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Stuff
On Sat, 3 Dec 2005 19:03:17 +0900 Carsten writes: > On Fri, 2 Dec 2005 01:06:25 -0500 Jose O Gonzalez <[EMAIL PROTECTED]> > babbled: > > > > > > > > > > > Just some attached evas stuff > > > > > > > > > > ok jose. i hate to do this can you > > > > > > 1. generate a diff: > > > > > > cd evas > > > cvs update -dP > > > cvs diff -U > ~/my_changes.diff > > > 2. any "new" added files... > > > > > > Attached it is :) There have been many changes to evas > recently, > > and here are yet more -- new blend funcs implementations, some > 'tweaks' > > to the scaling funcs, a few other minor things..., and fairly > extensive > > additions to evas' gradients capabilities.. > > > > I can go over them in detail later if desired, but for now > let's > > just get this sent before CVS evas changes again :) > > > > As always, you are free to do with this as you like, but > understand > > that nothing here has been checked or tested. > > ok. first. some style things... > > 1. dont do: > > int var = x; > int blah = 10; > > do: > > int var; > int blah = 10; > > var = x; > > basically DONT declare values of variables at declaration time, > unless its a > constant. > > 2. bracets. use them. > > do NOT do > > a + b * c >> 8; > do NOT do > a + (b * c) >> 8; > DO: > a + ((b * c) >> 8); > > i found some mistakes in your code that made the c fallbacks for the > scaler > code for upscaling images break due to lack of brackets. :) > Indeed, yes good point. I usually adhere to this quite rigorously, but as the hour grows late and the mind weary, my fingers tend to seek the path of 'fewer keystrokes' it seems... This is just one reason why it's so important to go over things and test them -- preferably to have someone else check things as well. Unfortunately, for this 'stuff', I was serious when I told you that I hadn't a chance to check the blending or scaling funcs :( > otherwise... > > good job! the gradients looke funky. very nice :) > Funky? Nah, quite conservative. But it should allow for most of what is needed for svg gradient support (I need to add another type of tiling/spread mode - "PAD" - the simplest one.. which I just forgot to get to). There are "issues" with some things - it could be much more optimal in some areas, and the filling just slams the color that fits the integer part.. this is for speed reasons, as one should really interpolate (as is done on 'edges') when aa, etc. And of course the GL engine is broken :( Will try to deal with it later if no one else does.. > and yes the evas > benchmarks > went up a bit - i did soem fiddling too myself. :) > Noticed that.. very nice :) BTW - Re the mm7 issue.. Recall sometime ago I once mentioned to you that I'd experienced a similar phenomenon... It's possible that this is being used 'behind our backs' to hold some intermediate values, maybe try using mm6 instead and see if that remains stable. Also, in the 'evas shutdown' function, there's no need to call the evas_font_dir_cache_free function, this is already called in the evas_common_shutdown function I introduced :) Ready for more 'stuff'? Jose. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] evas and shape mask calc
On Sun, 11 Dec 2005 13:59:10 +0900 Carsten writes: > On Sat, 10 Dec 2005 20:47:56 -0600 Brian Mattern > <[EMAIL PROTECTED]> > babbled: > > > Some recent commit (after the 2nd but before the 8th) broke evas > shape > > mask calculations. I'm going to go out on a limb and blame Jose's > > gradient patch :) > > correct. found it. the destination alpha math definitely gets things > wrong.. > like forgetting in 2's compliment binary math on single 32bit values > that > values can overflow... into the next, etc. unlike mmx/'sse where the > simd ops > protect the values form eachother... i ended up backign out all the > blend > changes as it just woudl take too long to debug it all. > > > For some reason regions that have transparent images blended onto > opaque > > ones get shaped out now. > > > > For an example, see: http://rephorm.com/files/shots/icky.png > > > > The AA parts of the text are shaped out, as is the window icon. > > This isn't noticeable in the default theme, since it doesn't use > shaping. > > > > I'll try to take a look, bu this isn't really my area of > expertise, so I > > wanted to let everyone else know about the issue (Raster and Jose > > especially). > > > > Take care, > > Brian > > U It's likely that some of the blend routines have bugs -- they were written very quickly, and went basically unchecked and untested. But it's also likely that most of them are fine.. they do need to be checked and tested. I'll see if I can get to that later -- but if you know of particular routines that are incorrect, let me know and I can look at them first :) Moving to pre-mul alpha is a good idea, but is *far* more radical in several respects, especially in relation to programs that have been getting/setting image data. Right now I was thinking of sending a small patch to add "rounded rectangles" to evas, but we'll see.. Jose. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] evas and shape mask calc
On Sun, 11 Dec 2005 23:51:24 +0900 Carsten writes: > On Sun, 11 Dec 2005 02:00:55 -0500 Jose O Gonzalez > <[EMAIL PROTECTED]> babbled: > > > > > > > On Sun, 11 Dec 2005 13:59:10 +0900 Carsten writes: > > > On Sat, 10 Dec 2005 20:47:56 -0600 Brian Mattern > > > <[EMAIL PROTECTED]> > > > babbled: > > > > > > > Some recent commit (after the 2nd but before the 8th) broke > evas > > > shape > > > > mask calculations. I'm going to go out on a limb and blame > Jose's > > > > gradient patch :) > > > > > > correct. found it. the destination alpha math definitely gets > things > > > wrong.. > > > like forgetting in 2's compliment binary math on single 32bit > values > > > that > > > values can overflow... into the next, etc. unlike mmx/'sse where > the > > > simd ops > > > protect the values form eachother... i ended up backign out all > the > > > blend > > > changes as it just woudl take too long to debug it all. > > > > > > > For some reason regions that have transparent images blended > onto > > > opaque > > > > ones get shaped out now. > > > > > > > > For an example, see: http://rephorm.com/files/shots/icky.png > > > > > > > > The AA parts of the text are shaped out, as is the window > icon. > > > > This isn't noticeable in the default theme, since it doesn't > use > > > shaping. > > > > > > > > I'll try to take a look, bu this isn't really my area of > > > expertise, so I > > > > wanted to let everyone else know about the issue (Raster and > Jose > > > > especially). > > > > > > > > Take care, > > > > Brian > > > > > > > > U It's likely that some of the blend routines > > have bugs -- they were written very quickly, and went basically > > unchecked and untested. But it's also likely that most of them > > are fine.. they do need to be checked and tested. I'll see if I > > can get to that later -- but if you know of particular routines > > that are incorrect, let me know and I can look at them first :) > > > > Moving to pre-mul alpha is a good idea, but is *far* > > more radical in several respects, especially in relation to > > programs that have been getting/setting image data. > > well it has other problems i wont go into here... :) there arent > that many > programs yet... thank god. > > > Right now I was thinking of sending a small patch to add > > "rounded rectangles" to evas, but we'll see.. > > for now - let it cool for a bit. i just reverted these :) > They'll remain in deep freeze til you let me know otherwise :) As far as the blend functions... From that one screenshot, it's unlikely that the dst-alpha blend functions are causing what is seen, since the areas where the src (icon and text) images are being drawn to, seem to be opague, and there the dst-alpha blend funcs just do non-dst-alpha blending.. Also, the corners aren't being touched by any src data, I presume, and yet they are not transparent, etc.. But I can't say much more from just that screenshot (I don't have the 'theme' or its images). I thus took a bit of time to run some tests on the blend funcs. Not exhaustive by any means, but a few... Blending to dst images with alpha, with src images with/without alpha, and with alpha masks plus colors with/without alpha, for both the c and mmx versions, and... I sure don't see any problems. But, you seem certain, and could well be right... > > > correct. found it. the destination alpha math definitely gets > things > > > wrong.. > > > like forgetting in 2's compliment binary math on single 32bit > values > > > that > > > values can overflow... into the next, etc. unlike mmx/'sse where > the > > > simd ops > > > protect the values form eachother... If you can tell me exactly which functions... :) --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] evas and shape mask calc
On Mon, 12 Dec 2005 17:39:29 +0900 Carsten writes: > On Mon, 12 Dec 2005 03:31:32 -0500 Jose O Gonzalez > <[EMAIL PROTECTED]> babbled: > > > They'll remain in deep freeze til you let me know > otherwise :) > > > > As far as the blend functions... > > > > From that one screenshot, it's unlikely that the dst-alpha > > blend functions are causing what is seen, since the areas where > > the src (icon and text) images are being drawn to, seem to be > opague, > > and there the dst-alpha blend funcs just do non-dst-alpha > blending.. > > Also, the corners aren't being touched by any src data, I presume, > > and yet they are not transparent, etc.. But I can't say much more > > from just that screenshot (I don't have the 'theme' or its > images). > > trust me - it was dst alpha calls - i had other exmaples too to work > with. i > know what fn was causing troubles in one example - and the same > logic was in > all the dst alpha blend routines. > I guess I'll have to take your word for it :) But in all the tests I ran (which, again, were rather few) no problems arose. Also, the code logic for the c and mmx versions are not the same, so it's unlikely that one would encouter the same problem with both (assuming you had problems with both). Note that the new blend functions are much more strict about wether or not an image (src or dst) has-alpha. > > I thus took a bit of time to run some tests on the blend > funcs. > > Not exhaustive by any means, but a few... Blending to dst images > > with alpha, with src images with/without alpha, and with alpha > masks > > plus colors with/without alpha, for both the c and mmx versions, > and... > > > > I sure don't see any problems. > > > > But, you seem certain, and could well be right... > > i am very certain :) > Yeah, but... we've been down this road once before... :) --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] evas and shape mask calc
On Mon, 12 Dec 2005 21:27:56 +0900 Carsten writes: > On Mon, 12 Dec 2005 05:12:11 -0500 Jose O Gonzalez > <[EMAIL PROTECTED]> babbled: > > > > > > > On Mon, 12 Dec 2005 17:39:29 +0900 Carsten writes: > > > On Mon, 12 Dec 2005 03:31:32 -0500 Jose O Gonzalez > > > <[EMAIL PROTECTED]> babbled: > > > > > > > They'll remain in deep freeze til you let me know > > > otherwise :) > > > > > > > > As far as the blend functions... > > > > > > > > From that one screenshot, it's unlikely that the > dst-alpha > > > > blend functions are causing what is seen, since the areas > where > > > > the src (icon and text) images are being drawn to, seem to be > > > opague, > > > > and there the dst-alpha blend funcs just do non-dst-alpha > > > blending.. > > > > Also, the corners aren't being touched by any src data, I > presume, > > > > and yet they are not transparent, etc.. But I can't say much > more > > > > from just that screenshot (I don't have the 'theme' or its > > > images). > > > > > > trust me - it was dst alpha calls - i had other exmaples too to > work > > > with. i > > > know what fn was causing troubles in one example - and the same > > > logic was in > > > all the dst alpha blend routines. > > > > > I guess I'll have to take your word for it :) But in all > the > > tests I ran (which, again, were rather few) no problems arose. > Also, > > the code logic for the c and mmx versions are not the same, so > it's > > unlikely > > that one would encouter the same problem with both (assuming you > had > > problems with both). > > they weren't the same - but i endede up backing it all out as i'd > instead end > up spedning a day on it piecemeal fixing it :) u should have tried > ecore_evas_test - hit the "s" key for a shaped canvas (destination > alpha) AND > disabled the mmx and sse routines (so it used the c routines > only).:) Ok, just now being able to get back to it :) No, I never tried running the ecore_evas test at all. I'll try it right -- now... With mmx default.. Pretty nice demo. I presume the bitmasking from the images' non-255 alpha values is correct? Recompiling with c as default.. U Yeah, definitely something amiss here :( > > > Note that the new blend functions are much more strict > about > > wether or not an image (src or dst) has-alpha. > > it's not that :) > No, I don't think it is either :( > > > > > > I thus took a bit of time to run some tests on the > blend > > > funcs. > > > > Not exhaustive by any means, but a few... Blending to dst > images > > > > with alpha, with src images with/without alpha, and with alpha > > > > masks > > > > plus colors with/without alpha, for both the c and mmx > versions, > > > and... > > > > > > > > I sure don't see any problems. Never did two or more images blended onto a dst-alpha image, overlaping each other, and this is what seems to bring out the problem. > > > > > > > > But, you seem certain, and could well be right... > > > > > > i am very certain :) > > > > > Yeah, but... we've been down this road once before... :) > > And you may well be on the right side of the road :) I'll take a look at what's going on and get back to you on it. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] evas and shape mask calc
On Tue, 13 Dec 2005 12:42:46 +0900 Carsten writes: > On Mon, 12 Dec 2005 20:41:12 -0500 Jose O Gonzalez > <[EMAIL PROTECTED]> babbled: > > > > > > > U Yeah, definitely something amiss here :( > > yeah. that was a good start in debugging, finding the algorithm > issues then > noting they were in many place then finally reverting. > > > > > I'll take a look at what's going on and get back to you on > > it. > Ok. Let me address this first and then pre-mul alpha :) It's fairly clear what's going on -- the approximations used aren't good enough to keep us within the [0-255] cube we want, so every once in a while the rgb computations overflow and bump the alpha up by one.. if the alpha was 255, it'll bump it 'up' to 0 :( Fortunately, there are simple enough solution(s): 1. We can do the computations with the components separately, as has been done so far... This is fairly painless, just replace ocurrances of the RGB_JOIN, ARGB_JOIN macros by the set of corresponding component-wise macros... Or, we can keep the new approach, which is somewhat faster, by noting that: 2. Since the only case where we need to worry about the dst alpha being overflowed is when it's 255, we can simply add one line wherever there's a switch statement over dst alpha and the case is 255.. namely we add the line A_VAL(dst) = 255; immediately after the RGB_JOIN macro that ocurrs there. This should solve the problem for rgba dst images. [ For rgb dst images, if we leave things as they are then their alphas may actually be changed, which is contrary to the spirit of things (the current code does this sometimes too), so if we want to be 'honest' then we should preserve whatever alpha the dst has.. and again we can first save its alpha and reset it, or whatever. ] I tried this just abit ago and... the ecore_evas_test shaped- evas demo is back to being on par with the mmx version :) (you only need to do it for the pixel-pixel rgba to rgba blend func for the demo) Either way, for the time being, if you feel comfortable with the mmx versions (and I still haven't really tested those!), then either of these two approaches, for the c versions, would be a good idea to put back in :) (the new blend routines do give some *good* speedups in many cases, not just from the mmx dst-alpha routines). > sure. though i think what we need iss to instead break out a small > routine set > outside of evas for optimising on its own first. i have a small > routine set of > more optimised pre-mul alpha c/mmx/sse/sse2 routines (sse3 provoides > nothing of > use i can see). they all work on x86 and amd64. it has a good speed > and > correctness test harness (write otu resulting png's of every op to > see if it > matches). :) Yeah, and that's pretty much what we've been doing :) I also wrote some c/mmx pre-mul alpha routines.. back when we first discussed it and such.. :) But moving *this* evas to pre-mul alpha is a big, *radical* change! Not only do all the blending/scaling/pixel-import, etc functions, have to be checked/changed/adapted, etc. that's just a lot of internals to be redone.. But every program and lib that's been getting/setting image data is going to be either broken, or it's going to suffer a major performance hit! > i actually get some interestign performance profiles > where > speedups vary. on amd64 sse2 is faster than sse by a bit (for > copies) but on my > p4 sse is faster than sse2 - by a bigger margin. int he end i > imagine we will > need a runtime routine check to see whihc is faster on that > particular cpu > (likely cache results unless cpu changes). > You're a nut!! But yes, I think a formal test/perfomace suite is an excellent idea.. clearly :) --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] evas and shape mask calc
On Tue, 13 Dec 2005 16:04:30 +0900 Carsten writes: > > > for now the only thing i have done are copy (blit) and > alpha blend > (with or without destination alpha). > > for C, mmx, sse and sse2 i have done: > done: > > * solid pixel copy forwards > * pixel blend > * pixel blend dst alpha > > to do: > > * solid pixel copy backwards > * solid color copy > * solid color blend > * solid color blend dst alpha > * color mul pixel copy > * color mul pixel blend > * color mul pixel blend dst alpha > * alpha mask color copy > * alpha mask color blend > * alpha mask color blend dst alpha > * alpha mask mul pixel copy > * alpha mask mul pixel blend > * alpha mask mul pixel blend dst alpha > * pixel argb mask mul pixel copy > * pixel argb mask mul pixel blend > * pixel argb mask mul pixel blend dst alpha > * yuv(yv12) to rgb > * yuva(yv12+a plane) to argb > * scale image (nearest) > * scale image (filtered) > * scale & rotate (transform) image non-repeat (nearest) > * scale & rotate (transform) image repeat (nearest) > * scale & rotate (transform) image non-repeat (smooth) > * scale & rotate (transform) image repeat (smooth) > * pixel box filter blurr copy > * pixel gaussian blurr copy > * alpha mask box filter blurr copy > * alpha mask gaussian blurr copy > > ok - so why so all of these separately? build a set of really really > realy > really fast routines to build "evas 2" software on top of. some of > these listed > are not in current evas. i think we can remove the cmod routines as > they arent > used and are just a pain. some of the aboive (yuv->rgb) exist > already in highly > optimsied format - it'll be hard to beat them - and an altivec one > to boot. Having these set apart from any given lib, plus a test suite, is a good step. While we're on the subject of 'blend' functions, let me remark on a couple of things. I've actually sat down on a couple of ocassions and wrote a few more of the ones listed above, pre-mul and non pre-mul alpha versions.. and so have you actually (eg. you have gaussian blurring in e). It's likely that nearly everyone out there has seen fit at some time to play around with such things Having fast c/mmx/sse/...xyz algorithms implementing compositing ops is great.. and doublets there are already plenty of excellent implementations out there already. But there are other things involved in 'common practice' use of gfx libs. This has been the thrust of my experimenting with these, and eg. the recent blend funcs I sent you were not really meant to provide particularly better algos for doing c or mmx compositing... What they were meant to do (besides adding mmx support to dst-alpha, in a truly banal way) was to continue with that experiment. It was to see how useful it would be - in "common use" - to split the functions into 'cases', as suitable... Wether it's testing per-pixel alpha triviality, or in choosing when to multiply alphas and/or colors, or in picking 'specialized' functions that assume certain things about its inputs, etc. You see, just providing two sets of (mask x color -> dst) functions, one for the case of color's alpha = 255, and another for color's alpha < 255, gives large gains in solid color text drawing over having one general-case function. Gains can go up by something like 30% if one can assume that the color is opague -- and this is very frequently the case for a large amount of text. These kinds of things will apply, in varying degrees, independent of the actual algos used for implementing the compositing. One other thing I'd mention here regarding compositing/transforming/etc image data is the issue of "quality".. Speed is necessary for real-time gfx use, but there are also needs that don't need speed and need instead the highest accuracy possible. Hence, I'd say that an option to set the level of "quality" (to say, "best") for rendering would be a good idea, and this in turn requires a similar set of such functions implemented so as to give the best agreement with the 'ideal' case. Other aspects are relevant as well, such as the question of supporting other compositing ops... > some other routines i want to create massively optimal subsystems > for: > > * detecting blit regions (this means making a very fast rect list > region > implementation that merges rects quickly on the fly and can do > boolean logic > (set, get, union, intersection, difference/cut) WITH motion vector > tags. > * better gradient fills (jose - you have this well in hand) > > this combined with the basic routines as above shoudl be enough to > implement > much more liek arbitray clipping, in-canvas blur filters (filter > objects to > blurr anything they "filter" like clip objects filter anything they > clip). we > should put these all into an external test harness and make ti work > then work > on merging it in later. :) > One thing that can also be done, besi
Re: [E-devel] [Patch] Evas -- poorly-placed ++'s
On Tue, 13 Dec 2005 12:47:56 -0800 David Sharp <[EMAIL PROTECTED]> writes: > On 12/13/05, Tilman Sauerbeck <[EMAIL PROTECTED]> wrote: > > Eric Sandall [2005-12-13 11:16]: > > > >while (dst < dst_end) > > > > - *dst++ = (*src++ | PIXEL_SOLID_ALPHA) & (*dst | > 0x00ff); > > > > + *dst = (*src | PIXEL_SOLID_ALPHA) & (*dst | 0x00ff); > > > > + dst++; > > > > + src++; > > > > } > > > > > > Shouldn't pre-increment (e.g. ++dst) be used instead of > post-increment > > > (e.g. dst++) as the post-increment in C, IIRC, requires the > object to > > > be copied, incremented, and then reassigned, whereas the > pre-increment > > > just increments without all the copying and reassigning. > > > > Since you cannot overload the ++ operator, and there are no > classes and > > objects in C, this doesn't apply to C at all. > > Well, a stupid compiler might save a copy before incrementing. but > even if it does, it would not copy the whole dst buffer (I guess > this > is what you would mean by "the object"), just the 32- (or 64-) bit > pointer. Any self-respecting compiler will see that the return value > of the increment is not used, and optimize it appropriately, even > with > -O0. Tilman is correct though, this applies more to C++, where the > incremented object could be a class, than to C, where you can only > increment integral and pointer types. > > The problem with the original code (which has since been removed > from > CVS for other reasons until Jose can work on it a little more) is > that > it does not take into account WHEN the increment happens.. Does it > happen before, or after the r-value is evaluated? (I believe this is > implementation-defined.) On my box, it was happening before, leaving > the dereference on the RHS to point one after the dst on the LHS, > and > caused a segfault for me when it reached over the end of the array > despite the bounds checking in the loop. A small, easy-to-miss > oversight by Jose. I was probably lucky that it segfaulted for me, > allowing me to find it, in fact. > > d# > Thanks for the kind words, deserved or not :) --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Stuff
On Wed, 14 Dec 2005 14:43:50 +0900 Carsten writes: > On Tue, 13 Dec 2005 23:38:43 -0500 Jason Tackaberry <[EMAIL PROTECTED]> > babbled: > > > On Tue, 2005-12-06 at 15:32 +0900, Carsten Haitzler wrote: > > > yeah - we ALSO need arbitratry clipping to any object, with an > added option > > > of pre-rendering all objects to be clipped by a clipper to a tmp > buffer, > > > unlike > > > > I'd settle for extending the current approach to support gradient > > objects as well, so that we can have a text fadeout effect. > > > > Currently I'm using this enormously brutal hack where I use Imlib2 > to > > render the text, modify the pixels directly, then use > > evas_object_image_data_set on an Evas image. Ugly. :) > > very ugly. the idea is that u could clip USING a gradient object > thus get what > u want. but for that we need pixel mask multiplication (render clip > mask, > render all objects to be clipped by it to a tmp buf, now composite > tmp buf to > destination, free tmp mask). when rendering the mask we can make a > few > shortcuts like cutr it up into only sub-object intersection regiosn > so we onyl > render/calculate the regions of the mask we will be needing for > multiplied dest > composite :) > Yeah, but you know the real difficulty here isn't the gfx aspects, at least not with the software based engines -- it's with the canvas level clipping semantics... Also, for the other engines, there's the need for the notion of the 'tmp' buffer to draw to... BTW, whatever happenned to that 'canvas-object' engine that you and someone else were working on (that was being discussed in irc) some weeks back? --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Is there a library within E to parse .desktop type files?
On Thu, 15 Dec 2005 11:25:36 +0900 Carsten writes: > On Thu, 15 Dec 2005 10:14:41 +0800 Phuah Yee Keat > <[EMAIL PROTECTED]> babbled: > > > Hi, > > > > I have checked the way KDM does autodetection of the sessions that > are > > available on the system, it uses its own set of ".desktop" files > (which > > we can just copy), and check to see if the executables are in the > system. > > > > I have did a quick check on the e_libs, but sees no library to > parse > > .desktop files, does Enlightenment need to parse these .desktop > files to > > be compliant with freedesktop? > > no - there's no lib/code to do it in cvs - but e17genmenu is an > importer. it > imports fd.o menus. fd.o menu configs are a pita to deal with. a > REAL PAIN. ask > devilhorns. parsing a .desktop file isnt so hard though - unlike the > xml mess > that is the menu spec. Better XML support by efls is something that should really be looked into.. For better or worse, this is something that is quickly becoming a 'must' for many things.. (and I would bet that if the edje 'edc' file format were in XML, one would see a lot more attention to this nice tool that Carsten created). jose. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Stuff
On Sat, 17 Dec 2005 18:40:50 +0900 Carsten writes: > On Wed, 14 Dec 2005 02:19:56 -0500 Jose O Gonzalez > <[EMAIL PROTECTED]> babbled: > > > > > > > On Wed, 14 Dec 2005 14:43:50 +0900 Carsten writes: > > > On Tue, 13 Dec 2005 23:38:43 -0500 Jason Tackaberry > <[EMAIL PROTECTED]> > > > babbled: > > > > > > > On Tue, 2005-12-06 at 15:32 +0900, Carsten Haitzler wrote: > > > > > yeah - we ALSO need arbitratry clipping to any object, with > an > > > added option > > > > > of pre-rendering all objects to be clipped by a clipper to a > tmp > > > buffer, > > > > > unlike > > > > > > > > I'd settle for extending the current approach to support > gradient > > > > objects as well, so that we can have a text fadeout effect. > > > > > > > > Currently I'm using this enormously brutal hack where I use > Imlib2 > > > to > > > > render the text, modify the pixels directly, then use > > > > evas_object_image_data_set on an Evas image. Ugly. :) > > > > > > very ugly. the idea is that u could clip USING a gradient object > > > > thus get what > > > u want. but for that we need pixel mask multiplication (render > clip > > > mask, > > > render all objects to be clipped by it to a tmp buf, now > composite > > > tmp buf to > > > destination, free tmp mask). when rendering the mask we can make > a > > > few > > > shortcuts like cutr it up into only sub-object intersection > regiosn > > > so we onyl > > > render/calculate the regions of the mask we will be needing for > > > multiplied dest > > > composite :) > > > > > Yeah, but you know the real difficulty here isn't the gfx > > aspects, at least not with the software based engines -- it's with > > the canvas level clipping semantics... > > well at the evas api level its expandable and ok. at the engine api > level its > bad atm. > The general clipping notion will *only* work coherently if an object may clip at most one other object. To 'clip' several objects one'd need to make them 'members' of some 'container' object (a smart obj, or a sub-canvas, or whatnot). But the canvas semantics *must* respect the single-clippee constraint. At the api level this requires no changes, and for the canvas internals it is actually a simplification (also need to remove the smartobj clip_object_set and color_set functs). The problem is (from what little I've looked at of edje), that going thru with this seems like it would break edje as it is. You'd need to make sure, when the format specifies multiple objects being 'clipped' by some object, that you collect these into a separate smart obj that will be the actual clipped obj. If you can do this.. then the evas changes are not difficult (at least not for the software based engines). --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Rounded evas rectangles
Attached is a fairly small and simple patch to evas for adding "rounded rectangles". This is just on top of the usual evas rectangle object. The new api calls are just: evas_object_rectangle_rounded_set(obj, Evas_Coord rx, Evas_Coord ry, Evas_Bool tl, Evas_Bool tr, Evas_Bool bl, Evas_Bool br); and a similar 'get' function. The 'rx', 'ry' vars are for setting the amount of rounding desired - one will get circular rounding setting rx = ry, ow. one'll get elliptical rounding of the corners. The 'tl', 'tr', 'bl', 'br' vars are for choosing which of the four corners to round or not, ie. topl-left, top-right, etc. Only the software based engines have this right now, and it's just something to play with.. if you're so inclined. Again, this has NOT been tested! But if you feel brave, feel free to do with as you wish :) jose. evas_rect.diff.gz Description: Binary data
Re: [E-devel] evas_object_text_style_render segv patch
On Sat, 14 Jan 2006 01:33:51 + Alastair Tse <[EMAIL PROTECTED]> writes: > Hi, > > I've been playing around with evas for a while now and I came across > this segv when I was playing trying to use > evas_object_text_style_set(). > > I discovered that in evas/src/lib/canvas/evas_object_text.c, the > evas_object_text_render() method assumes there's a clipping object > when > setting the outline/shadow colors. > > Here's a quick patch to fix the problem. I'm not quite sure whether > I > understand it, but I don't set clip objects usually, is that > required? > > Cheers, > > Alastair > I doubt raster meant for a clip obj to be 'required'.. possibly in that code he may have meant obj->cur.cache.clip.r,g,b,a rather than obj->cur.clipper->cur.cache.clip.r,g,b,a -- But more likely he meant to use the clipper only when it exists, as you have in the patch.. :) jose. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] evas_object_text_style_render segv patch
On Sat, 14 Jan 2006 18:21:49 +0900 Carsten writes: > On Sat, 14 Jan 2006 01:33:51 + Alastair Tse <[EMAIL PROTECTED]> > babbled: > > > Hi, > > > > I've been playing around with evas for a while now and I came > across > > this segv when I was playing trying to use > evas_object_text_style_set(). > > > > I discovered that in evas/src/lib/canvas/evas_object_text.c, the > > evas_object_text_render() method assumes there's a clipping object > when > > setting the outline/shadow colors. > > > > Here's a quick patch to fix the problem. I'm not quite sure > whether I > > understand it, but I don't set clip objects usually, is that > required? > > > > Cheers, > > yup- good catch. thanks. - no i didnt mean the cached clip color as > thats the > object color multiplied by the clip color (stored) - not what i want > here. :) > It was meant as a 'hint' from me :) For various reasons, it is best if the general obj color setting api func actually colors the obj as a 'whole', so that it would be equivalent to first rendering the obj with color = 0x to a buffer say and then coloring that image buf with the original color. In other words -- if an object has several 'internal' means of 'coloring' parts of itself (here the text obj has such), then the general obj color should multiply these.. ie. the general object color should always act like a clip color. Without that, there will be "problems" ... But also you would like to be able to re-color an object simply by setting the object's color, rather than having to have to set a clip-obj (which, oddly, has *its* color set as the desired re-coloring color). For the particular case of text objs, which have gained 'styling' via api functs for setting the text's shadow, glow, etc. colors, one would need to also add an api funct for setting say the 'main' color of the text (as opposed to setting the color of the 'text-object'). jose. PS. Lots of new stuff there in evas CVS, congrats to all who put in so much work :) --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] gfx_routines
> Enlightenment CVS committal > > Author : raster > Project : e17 > Module : proto > > Dir : e17/proto/gfx_routines > > > Modified Files: > blend.c > > > Log Message: > > > jose came up with some nice idea for a faster c blender... much nicer :) > Oh no, I can't take credit for coming up with that particular routine. I spent an hour coming up with a variety of c blend routines, some nearly fast (but not quite) as that one, but via a different means, and some that were similar in approach but gave incorrect results for the alpha component... I suspected there was a way to do it via that approach, but I ran out of time and didn't think I was going to get it any time soon... So I decided to take look at what's being done by the people who actually do know what they're doing - namely I took a look at the xserver sources. There, in the CVS dir "xserver/fb/fbpict.h" I found some code that gave me the missing piece for how to do this - it was then a trivial matter to write things out as we wanted them. All credit must go to whoever came up with the idea found in that xserver code, not me. jose. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] members-only: question
If subscribing to this list qualifies one as a "member", is it possible to obtain a free catalogue of E paraphernalia, e.g. E Tshirts, Coffee Mugs, etc... ? Also, who is "Raster" or "The Rasterman", and what exactly is his connection with Enlightenment? jose. PS. While there's coverage of some things spread around, a "History" section on the Enlightenment website could be something people might find interesting -- perhaps with some screenshots of earlier versions and such -- after all, were there ever "DRx", for 0http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ enlightenment-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Evas patches
What follows is the first in a series of patches
designed to speed up some of Evas' drawing/blending
C functions in the "engines/common" dir.
As later patches will involve non-trivial changes,
this first *very small* one is merely to fix a minor oversight
and add a trivial check in the line drawing function of the
file "evas_line_main.c".
One question though: Is there a reason for not using
say Imlib2's anti-aliased line drawing algorithm here?
jose.
Index: cvs/e17/libs/evas/src/lib/engines/common/evas_line_main.c
===
RCS file:
/cvsroot/enlightenment/e17/libs/evas/src/lib/engines/common/evas_line_mai
n.c,v
retrieving revision 1.4
diff -u -r1.4 evas_line_main.c
--- cvs/e17/libs/evas/src/lib/engines/common/evas_line_main.c 26 Jan 2004
03:31:39 - 1.4
+++ cvs/e17/libs/evas/src/lib/engines/common/evas_line_main.c 15 Mar 2004
07:46:22 -
@@ -31,6 +31,9 @@
sx = SGN(dx);
sy = SGN(dy);
+ col = dc->col.col;
+ if (!A_VAL(&(col))) return;
+
if ((dx == 0) && (dy == 0))
{
if ((x1 < 0) ||
@@ -86,7 +89,6 @@
im = dst->image->data;
im_w = dst->image->w;
im_h = dst->image->h;
- col = dc->col.col;
ext_x = 0; ext_y = 0; ext_w = im_w; ext_h = im_h;
if (dc->clip.use)
---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
___
enlightenment-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Evas patches -- 2
This is the second in a series of patches to Evas files.
The main thrust of these is to "improve" the drawing/blending
C functions in the "engines/common" dir via the following:
1) Replace the current formula for the new destination
alpha (when blending to rgba) by the formula
BLEND_COLOR(a, A_VAL(dst), 255, A_VAL(dst), tmp)
where "a" is the relevant alpha value.
2) Add tests, where appropiate, for the blending alpha
value cases 0 and 255, and replace the latter with simpler 'copy'
type equations.
3) Improve the accuracy of the "blend_alpha_color_pixel"
and "blend_pixel_mult_pixel" types of functions by replacing
equations of the form
nc = ((c + 1) * cc) >> 8
with a macro defined by
MULT_COLOR(nc, c, cc, tmp)\
{ \
(tmp) = (c) * (cc); \
(nc) = ((tmp) + ((tmp) >> 8) + 0x80) >> 8; \
}
This can also be defined as BLEND_COLOR(c, nc, cc, 0, tmp),
but I believe it merits its own separate definition.
The macro has been added to the file "evas_common.h"
of the "include" dir, and is used by some of the subsequent
patches.
This patch involves the above mentioned file, and the
file "evas_blend_ops.h"
jose.
-
--
for evas_blend_ops.h
--
Index: cvs/e17/libs/evas/src/lib/engines/common/evas_blend_ops.h
===
RCS file:
/cvsroot/enlightenment/e17/libs/evas/src/lib/engines/common/evas_blend_op
s.h,v
retrieving revision 1.1
diff -u -r1.1 evas_blend_ops.h
--- cvs/e17/libs/evas/src/lib/engines/common/evas_blend_ops.h 30 Jan 2004
05:46:57 - 1.1
+++ cvs/e17/libs/evas/src/lib/engines/common/evas_blend_ops.h 17 Mar 2004
07:32:45 -
@@ -9,6 +9,9 @@
if (A_VAL(src)) /* hmmm - do we need this? */ \
{ \
__a = _evas_pow_lut[A_VAL(src)][A_VAL(dst)]; \
+ BLEND_COLOR(A_VAL(src), A_VAL(dst), \
+ 255, A_VAL(dst), \
+ __tmp); \
BLEND_COLOR(__a, R_VAL(dst), \
R_VAL(src), R_VAL(dst), \
__tmp); \
@@ -18,7 +21,6 @@
BLEND_COLOR(__a, B_VAL(dst), \
B_VAL(src), B_VAL(dst), \
__tmp); \
- A_VAL(dst) = A_VAL(dst) + ((A_VAL(src) * (255 - A_VAL(dst))) / 255);\
} \
}
--
for evas_common.h
--
Index: cvs/e17/libs/evas/src/lib/include/evas_common.h
===
RCS file:
/cvsroot/enlightenment/e17/libs/evas/src/lib/include/evas_common.h,v
retrieving revision 1.23
diff -u -r1.23 evas_common.h
--- cvs/e17/libs/evas/src/lib/include/evas_common.h 30 Jan 2004 05:46:57
- 1.23
+++ cvs/e17/libs/evas/src/lib/include/evas_common.h 17 Mar 2004 07:17:19
-
@@ -545,6 +545,12 @@
#define PIXEL_SOLID_ALPHA 0xff00
+#define MULT_COLOR(nc, c, cc, tmp)\
+{ \
+ (tmp) = (c) * (cc); \
+ (nc) = ((tmp) + ((tmp) >> 8) + 0x80) >> 8; \
+}
+
#define SPANS_COMMON(x1, w1, x2, w2) \
(!x2) + (w2)) <= (x1)) || ((x2) >= ((x1) + (w1)
#define RECTS_INTERSECT(x, y, w, h, xx, yy, ww, hh) \
---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
___
enlightenment-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Evas patches -- 3
This patch, the third in a series, involves the file
"evas_blend_alpha_color_pixel.c" of the "engines/common" dir.
jose.
---
Index:
cvs/e17/libs/evas/src/lib/engines/common/evas_blend_alpha_color_pixel.c
===
RCS file:
/cvsroot/enlightenment/e17/libs/evas/src/lib/engines/common/evas_blend_al
pha_color_pixel.c,v
retrieving revision 1.3
diff -u -r1.3 evas_blend_alpha_color_pixel.c
---
cvs/e17/libs/evas/src/lib/engines/common/evas_blend_alpha_color_pixel.c 1
2 May 2003 02:26:26 - 1.3
+++
cvs/e17/libs/evas/src/lib/engines/common/evas_blend_alpha_color_pixel.c 1
7 Mar 2004 07:16:08 -
@@ -18,12 +18,43 @@
dst_ptr = dst;
dst_end_ptr = dst + len;
+ if (A_VAL(&col) < 0xff)
+ {
+ while (dst_ptr < dst_end_ptr)
+ {
+ DATA32 tmp;
+ DATA8 aa;
+
+ MULT_COLOR(aa, *src_ptr, A_VAL(&col), tmp);
+ if (!aa) { src_ptr++; dst_ptr++; continue; }
+ BLEND_COLOR(aa, R_VAL(dst_ptr),
+ R_VAL(&col), R_VAL(dst_ptr),
+ tmp);
+ BLEND_COLOR(aa, G_VAL(dst_ptr),
+ G_VAL(&col), G_VAL(dst_ptr),
+ tmp);
+ BLEND_COLOR(aa, B_VAL(dst_ptr),
+ B_VAL(&col), B_VAL(dst_ptr),
+ tmp);
+
+ src_ptr++;
+ dst_ptr++;
+ }
+ return;
+ }
+
while (dst_ptr < dst_end_ptr)
{
DATA32 tmp;
DATA8 aa;
- aa = (((*src_ptr) +1) * A_VAL(&col)) >> 8;
+ aa = *src_ptr;
+ if (!aa) { src_ptr++; dst_ptr++; continue; }
+ if (aa = 0xff)
+{
+ *dst_ptr = col;
+ src_ptr++; dst_ptr++; continue;
+}
BLEND_COLOR(aa, R_VAL(dst_ptr),
R_VAL(&col), R_VAL(dst_ptr),
tmp);
@@ -33,6 +64,7 @@
BLEND_COLOR(aa, B_VAL(dst_ptr),
B_VAL(&col), B_VAL(dst_ptr),
tmp);
+
src_ptr++;
dst_ptr++;
}
@@ -117,15 +149,53 @@
dst_ptr = dst;
dst_end_ptr = dst + len;
+ if (A_VAL(&col) < 0xff)
+ {
+ while (dst_ptr < dst_end_ptr)
+ {
+ DATA32 tmp;
+ DATA8 a;
+ DATA8 aa;
+
+ MULT_COLOR(aa, *src_ptr, A_VAL(&col), tmp);
+ if (!aa) { src_ptr++; dst_ptr++; continue; }
+ a = _evas_pow_lut[aa][A_VAL(dst_ptr)];
+ BLEND_COLOR(aa, A_VAL(dst_ptr),
+ 255, A_VAL(dst_ptr),
+ tmp);
+ BLEND_COLOR(a, R_VAL(dst_ptr),
+ R_VAL(&col), R_VAL(dst_ptr),
+ tmp);
+ BLEND_COLOR(a, G_VAL(dst_ptr),
+ G_VAL(&col), G_VAL(dst_ptr),
+ tmp);
+ BLEND_COLOR(a, B_VAL(dst_ptr),
+ B_VAL(&col), B_VAL(dst_ptr),
+ tmp);
+
+ src_ptr++;
+ dst_ptr++;
+ }
+ return;
+ }
+
while (dst_ptr < dst_end_ptr)
{
DATA32 tmp;
DATA8 a;
DATA8 aa;
- aa = (((*src_ptr) + 1) * A_VAL(&col)) >> 8;
- a = _evas_pow_lut[aa][A_VAL(dst_ptr)];
-
+ aa = *src_ptr;
+ if (!aa) { src_ptr++; dst_ptr++; continue; }
+ if (aa = 0xff)
+{
+ *dst_ptr = col;
+ src_ptr++; dst_ptr++; continue;
+}
+ a = _evas_pow_lut[aa][A_VAL(dst_ptr)];
+ BLEND_COLOR(aa, A_VAL(dst_ptr),
+ 255, A_VAL(dst_ptr),
+ tmp);
BLEND_COLOR(a, R_VAL(dst_ptr),
R_VAL(&col), R_VAL(dst_ptr),
tmp);
@@ -135,7 +205,7 @@
BLEND_COLOR(a, B_VAL(dst_ptr),
B_VAL(&col), B_VAL(dst_ptr),
tmp);
- A_VAL(dst_ptr) = A_VAL(dst_ptr) + ((aa * (255 - A_VAL(dst_ptr))) /
255);
+
src_ptr++;
dst_ptr++;
}
---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
___
enlightenment-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Evas patches -- 4
This patch, the fourth in a series, involves the file
"evas_blend_pixel_pixel.c" of the "engines/common" dir.
jose.
---
Index: cvs/e17/libs/evas/src/lib/engines/common/evas_blend_pixel_pixel.c
===
RCS file:
/cvsroot/enlightenment/e17/libs/evas/src/lib/engines/common/evas_blend_pi
xel_pixel.c,v
retrieving revision 1.5
diff -u -r1.5 evas_blend_pixel_pixel.c
--- cvs/e17/libs/evas/src/lib/engines/common/evas_blend_pixel_pixel.c 10
Sep 2003 08:52:17 - 1.5
+++ cvs/e17/libs/evas/src/lib/engines/common/evas_blend_pixel_pixel.c 17
Mar 2004 07:14:59 -
@@ -20,19 +20,25 @@
while (dst_ptr < dst_end_ptr)
{
DATA32 tmp;
+ DATA8 a;
- if (A_VAL(src_ptr)) /* hmmm - do we need this? */
+ a = A_VAL(src_ptr);
+ if (!a) { src_ptr++; dst_ptr++; continue; }
+ if (a == 0xff)
+ {
+*dst_ptr = *src_ptr;
+src_ptr++; dst_ptr++; continue; }
{
-BLEND_COLOR(A_VAL(src_ptr), R_VAL(dst_ptr),
-R_VAL(src_ptr), R_VAL(dst_ptr),
-tmp);
-BLEND_COLOR(A_VAL(src_ptr), G_VAL(dst_ptr),
-G_VAL(src_ptr), G_VAL(dst_ptr),
-tmp);
-BLEND_COLOR(A_VAL(src_ptr), B_VAL(dst_ptr),
-B_VAL(src_ptr), B_VAL(dst_ptr),
-tmp);
- }
+ BLEND_COLOR(a, R_VAL(dst_ptr),
+ R_VAL(src_ptr), R_VAL(dst_ptr),
+ tmp);
+ BLEND_COLOR(a, G_VAL(dst_ptr),
+ G_VAL(src_ptr), G_VAL(dst_ptr),
+ tmp);
+ BLEND_COLOR(a, B_VAL(dst_ptr),
+ B_VAL(src_ptr), B_VAL(dst_ptr),
+ tmp);
+
src_ptr++;
dst_ptr++;
}
@@ -97,21 +103,27 @@
DATA32 tmp;
DATA8 a;
- if (A_VAL(src_ptr)) /* hmmm - do we need this? */
+ a = A_VAL(src_ptr);
+ if (!a) { src_ptr++; dst_ptr++; continue; }
+ if (a == 0xff)
+ {
+*dst_ptr = *src_ptr;
+src_ptr++; dst_ptr++; continue; }
{
-a = _evas_pow_lut[A_VAL(src_ptr)][A_VAL(dst_ptr)];
+ a = _evas_pow_lut[a][A_VAL(dst_ptr)];
+ BLEND_COLOR(A_VAL(src_ptr), A_VAL(dst_ptr),
+ 255, A_VAL(dst_ptr),
+ tmp);
+ BLEND_COLOR(a, R_VAL(dst_ptr),
+ R_VAL(src_ptr), R_VAL(dst_ptr),
+ tmp);
+ BLEND_COLOR(a, G_VAL(dst_ptr),
+ G_VAL(src_ptr), G_VAL(dst_ptr),
+ tmp);
+ BLEND_COLOR(a, B_VAL(dst_ptr),
+ B_VAL(src_ptr), B_VAL(dst_ptr),
+ tmp);
-BLEND_COLOR(a, R_VAL(dst_ptr),
-R_VAL(src_ptr), R_VAL(dst_ptr),
-tmp);
-BLEND_COLOR(a, G_VAL(dst_ptr),
-G_VAL(src_ptr), G_VAL(dst_ptr),
-tmp);
-BLEND_COLOR(a, B_VAL(dst_ptr),
-B_VAL(src_ptr), B_VAL(dst_ptr),
-tmp);
-A_VAL(dst_ptr) = A_VAL(dst_ptr) + ((A_VAL(src_ptr) * (255 -
A_VAL(dst_ptr))) / 255);
- }
src_ptr++;
dst_ptr++;
}
---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
___
enlightenment-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Evas patches -- 3 - revised
In a couple of places an "=" got in where it should be "==", here is the
revised
version of the patch to the file "evas_blend_alpha_color_pixel.c".
jose.
-
Index:
cvs/e17/libs/evas/src/lib/engines/common/evas_blend_alpha_color_pixel.c
===
RCS file:
/cvsroot/enlightenment/e17/libs/evas/src/lib/engines/common/evas_blend_al
pha_color_pixel.c,v
retrieving revision 1.3
diff -u -r1.3 evas_blend_alpha_color_pixel.c
---
cvs/e17/libs/evas/src/lib/engines/common/evas_blend_alpha_color_pixel.c 1
2 May 2003 02:26:26 - 1.3
+++
cvs/e17/libs/evas/src/lib/engines/common/evas_blend_alpha_color_pixel.c 1
7 Mar 2004 18:51:22 -
@@ -18,12 +18,43 @@
dst_ptr = dst;
dst_end_ptr = dst + len;
+ if (A_VAL(&col) < 0xff)
+ {
+ while (dst_ptr < dst_end_ptr)
+ {
+ DATA32 tmp;
+ DATA8 aa;
+
+ MULT_COLOR(aa, *src_ptr, A_VAL(&col), tmp);
+ if (!aa) { src_ptr++; dst_ptr++; continue; }
+ BLEND_COLOR(aa, R_VAL(dst_ptr),
+ R_VAL(&col), R_VAL(dst_ptr),
+ tmp);
+ BLEND_COLOR(aa, G_VAL(dst_ptr),
+ G_VAL(&col), G_VAL(dst_ptr),
+ tmp);
+ BLEND_COLOR(aa, B_VAL(dst_ptr),
+ B_VAL(&col), B_VAL(dst_ptr),
+ tmp);
+
+ src_ptr++;
+ dst_ptr++;
+ }
+ return;
+ }
+
while (dst_ptr < dst_end_ptr)
{
DATA32 tmp;
DATA8 aa;
- aa = (((*src_ptr) +1) * A_VAL(&col)) >> 8;
+ aa = *src_ptr;
+ if (!aa) { src_ptr++; dst_ptr++; continue; }
+ if (aa == 0xff)
+{
+ *dst_ptr = col;
+ src_ptr++; dst_ptr++; continue;
+}
BLEND_COLOR(aa, R_VAL(dst_ptr),
R_VAL(&col), R_VAL(dst_ptr),
tmp);
@@ -33,6 +64,7 @@
BLEND_COLOR(aa, B_VAL(dst_ptr),
B_VAL(&col), B_VAL(dst_ptr),
tmp);
+
src_ptr++;
dst_ptr++;
}
@@ -117,15 +149,53 @@
dst_ptr = dst;
dst_end_ptr = dst + len;
+ if (A_VAL(&col) < 0xff)
+ {
+ while (dst_ptr < dst_end_ptr)
+ {
+ DATA32 tmp;
+ DATA8 a;
+ DATA8 aa;
+
+ MULT_COLOR(aa, *src_ptr, A_VAL(&col), tmp);
+ if (!aa) { src_ptr++; dst_ptr++; continue; }
+ a = _evas_pow_lut[aa][A_VAL(dst_ptr)];
+ BLEND_COLOR(aa, A_VAL(dst_ptr),
+ 255, A_VAL(dst_ptr),
+ tmp);
+ BLEND_COLOR(a, R_VAL(dst_ptr),
+ R_VAL(&col), R_VAL(dst_ptr),
+ tmp);
+ BLEND_COLOR(a, G_VAL(dst_ptr),
+ G_VAL(&col), G_VAL(dst_ptr),
+ tmp);
+ BLEND_COLOR(a, B_VAL(dst_ptr),
+ B_VAL(&col), B_VAL(dst_ptr),
+ tmp);
+
+ src_ptr++;
+ dst_ptr++;
+ }
+ return;
+ }
+
while (dst_ptr < dst_end_ptr)
{
DATA32 tmp;
DATA8 a;
DATA8 aa;
- aa = (((*src_ptr) + 1) * A_VAL(&col)) >> 8;
- a = _evas_pow_lut[aa][A_VAL(dst_ptr)];
-
+ aa = *src_ptr;
+ if (!aa) { src_ptr++; dst_ptr++; continue; }
+ if (aa == 0xff)
+{
+ *dst_ptr = col;
+ src_ptr++; dst_ptr++; continue;
+}
+ a = _evas_pow_lut[aa][A_VAL(dst_ptr)];
+ BLEND_COLOR(aa, A_VAL(dst_ptr),
+ 255, A_VAL(dst_ptr),
+ tmp);
BLEND_COLOR(a, R_VAL(dst_ptr),
R_VAL(&col), R_VAL(dst_ptr),
tmp);
@@ -135,7 +205,7 @@
BLEND_COLOR(a, B_VAL(dst_ptr),
B_VAL(&col), B_VAL(dst_ptr),
tmp);
- A_VAL(dst_ptr) = A_VAL(dst_ptr) + ((aa * (255 - A_VAL(dst_ptr))) /
255);
+
src_ptr++;
dst_ptr++;
}
---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
___
enlightenment-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Evas patches -- 5
This patch, the fith in a series, involves the file
"evas_blend_pixel_cmod_pixel.c" of the "engines/common" dir.
jose.
---
Index:
cvs/e17/libs/evas/src/lib/engines/common/evas_blend_pixel_cmod_pixel.c
===
RCS file:
/cvsroot/enlightenment/e17/libs/evas/src/lib/engines/common/evas_blend_pi
xel_cmod_pixel.c,v
retrieving revision 1.3
diff -u -r1.3 evas_blend_pixel_cmod_pixel.c
---
cvs/e17/libs/evas/src/lib/engines/common/evas_blend_pixel_cmod_pixel.c 12
May 2003 02:26:26 - 1.3
+++
cvs/e17/libs/evas/src/lib/engines/common/evas_blend_pixel_cmod_pixel.c 17
Mar 2004 18:52:31 -
@@ -22,18 +22,23 @@
DATA8 a;
a = amod[A_VAL(src_ptr)];
- if (a) /* hmmm - do we need this? */
+ if (!a) { src_ptr++; dst_ptr++; continue; }
+ if (a == 0xff)
{
-BLEND_COLOR(a, R_VAL(dst_ptr),
-rmod[R_VAL(src_ptr)], R_VAL(dst_ptr),
-tmp);
-BLEND_COLOR(a, G_VAL(dst_ptr),
-gmod[G_VAL(src_ptr)], G_VAL(dst_ptr),
-tmp);
-BLEND_COLOR(a, B_VAL(dst_ptr),
-bmod[B_VAL(src_ptr)], B_VAL(dst_ptr),
-tmp);
+ R_VAL(dst_ptr) = rmod[R_VAL(src_ptr)];
+ G_VAL(dst_ptr) = gmod[G_VAL(src_ptr)];
+ B_VAL(dst_ptr) = bmod[B_VAL(src_ptr)];
+ src_ptr++; dst_ptr++; continue;
}
+ BLEND_COLOR(a, R_VAL(dst_ptr),
+ rmod[R_VAL(src_ptr)], R_VAL(dst_ptr),
+ tmp);
+ BLEND_COLOR(a, G_VAL(dst_ptr),
+ gmod[G_VAL(src_ptr)], G_VAL(dst_ptr),
+ tmp);
+ BLEND_COLOR(a, B_VAL(dst_ptr),
+ bmod[B_VAL(src_ptr)], B_VAL(dst_ptr),
+ tmp);
src_ptr++;
dst_ptr++;
}
@@ -53,22 +58,31 @@
while (dst_ptr < dst_end_ptr)
{
DATA32 tmp;
- DATA8 a;
+ DATA8 a, aa;
- a = _evas_pow_lut[amod[A_VAL(src_ptr)]][A_VAL(dst_ptr)];
- if (a) /* hmmm - do we need this? */
+ aa = amod[A_VAL(src_ptr)];
+ if (!aa) { src_ptr++; dst_ptr++; continue; }
+ if (aa == 0xff)
{
-BLEND_COLOR(a, R_VAL(dst_ptr),
-rmod[R_VAL(src_ptr)], R_VAL(dst_ptr),
-tmp);
-BLEND_COLOR(a, G_VAL(dst_ptr),
-gmod[G_VAL(src_ptr)], G_VAL(dst_ptr),
-tmp);
-BLEND_COLOR(a, B_VAL(dst_ptr),
-bmod[B_VAL(src_ptr)], B_VAL(dst_ptr),
-tmp);
-A_VAL(dst_ptr) = A_VAL(dst_ptr) + ((amod[A_VAL(src_ptr)] * (255 -
A_VAL(dst_ptr))) / 255);
+ A_VAL(dst_ptr) = 0xff;
+ R_VAL(dst_ptr) = rmod[R_VAL(src_ptr)];
+ G_VAL(dst_ptr) = gmod[G_VAL(src_ptr)];
+ B_VAL(dst_ptr) = bmod[B_VAL(src_ptr)];
+ src_ptr++; dst_ptr++; continue;
}
+ a = _evas_pow_lut[aa][A_VAL(dst_ptr)];
+ BLEND_COLOR(aa, A_VAL(dst_ptr),
+ 255, A_VAL(dst_ptr),
+ tmp);
+ BLEND_COLOR(a, R_VAL(dst_ptr),
+ rmod[R_VAL(src_ptr)], R_VAL(dst_ptr),
+ tmp);
+ BLEND_COLOR(a, G_VAL(dst_ptr),
+ gmod[G_VAL(src_ptr)], G_VAL(dst_ptr),
+ tmp);
+ BLEND_COLOR(a, B_VAL(dst_ptr),
+ bmod[B_VAL(src_ptr)], B_VAL(dst_ptr),
+ tmp);
src_ptr++;
dst_ptr++;
}
---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
___
enlightenment-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Evas patches -- 6
This patch, the six -- and last -- in a series, involves the file
"evas_blend_pixel_mul_pixel.c" of the "engines/common" dir.
jose.
---
Index:
cvs/e17/libs/evas/src/lib/engines/common/evas_blend_pixel_mul_pixel.c
===
RCS file:
/cvsroot/enlightenment/e17/libs/evas/src/lib/engines/common/evas_blend_pi
xel_mul_pixel.c,v
retrieving revision 1.3
diff -u -r1.3 evas_blend_pixel_mul_pixel.c
---
cvs/e17/libs/evas/src/lib/engines/common/evas_blend_pixel_mul_pixel.c 12
May 2003 02:26:26 - 1.3
+++
cvs/e17/libs/evas/src/lib/engines/common/evas_blend_pixel_mul_pixel.c 17
Mar 2004 18:53:03 -
@@ -26,46 +26,71 @@
DATA32 tmp;
DATA8 a;
-a = (A_VAL(src_ptr) * (A_VAL(&mul_color) + 1)) >> 8;
-if (a) /* hmmm - do we need this? */
- {
- BLEND_COLOR(a, R_VAL(dst_ptr),
- R_VAL(src_ptr), R_VAL(dst_ptr),
- tmp);
- BLEND_COLOR(a, G_VAL(dst_ptr),
- G_VAL(src_ptr), G_VAL(dst_ptr),
- tmp);
- BLEND_COLOR(a, B_VAL(dst_ptr),
- B_VAL(src_ptr), B_VAL(dst_ptr),
- tmp);
- }
+MULT_COLOR(a, A_VAL(src_ptr), A_VAL(&mul_color), tmp);
+if (!a) { src_ptr++; dst_ptr++; continue; }
+
+BLEND_COLOR(a, R_VAL(dst_ptr),
+R_VAL(src_ptr), R_VAL(dst_ptr),
+tmp);
+BLEND_COLOR(a, G_VAL(dst_ptr),
+G_VAL(src_ptr), G_VAL(dst_ptr),
+tmp);
+BLEND_COLOR(a, B_VAL(dst_ptr),
+B_VAL(src_ptr), B_VAL(dst_ptr),
+tmp);
+
src_ptr++;
dst_ptr++;
}
+ return;
}
- else
+
+ if (A_VAL(&mul_color) < 0xff)
{
while (dst_ptr < dst_end_ptr)
{
DATA32 tmp;
-DATA8 a;
-
-a = (A_VAL(src_ptr) * (A_VAL(&mul_color) + 1)) >> 8;
-if (a) /* hmmm - do we need this? */
- {
- BLEND_COLOR(a, R_VAL(dst_ptr),
- ((R_VAL(src_ptr) * (R_VAL(&mul_color) + 1)) >> 8),
R_VAL(dst_ptr),
- tmp);
- BLEND_COLOR(a, G_VAL(dst_ptr),
- ((G_VAL(src_ptr) * (G_VAL(&mul_color) + 1)) >> 8),
G_VAL(dst_ptr),
- tmp);
- BLEND_COLOR(a, B_VAL(dst_ptr),
- ((B_VAL(src_ptr) * (B_VAL(&mul_color) + 1)) >> 8),
B_VAL(dst_ptr),
- tmp);
- }
+DATA8 a, r, g, b;
+
+MULT_COLOR(a, A_VAL(src_ptr), A_VAL(&mul_color), tmp);
+if (!a) { src_ptr++; dst_ptr++; continue; }
+
+MULT_COLOR(r, R_VAL(src_ptr), R_VAL(&mul_color), tmp);
+BLEND_COLOR(a, R_VAL(dst_ptr), r, R_VAL(dst_ptr), tmp);
+MULT_COLOR(g, G_VAL(src_ptr), G_VAL(&mul_color), tmp);
+BLEND_COLOR(a, G_VAL(dst_ptr), g, G_VAL(dst_ptr), tmp);
+MULT_COLOR(b, B_VAL(src_ptr), B_VAL(&mul_color), tmp);
+BLEND_COLOR(a, B_VAL(dst_ptr), b, B_VAL(dst_ptr), tmp);
+
src_ptr++;
dst_ptr++;
}
+ return;
+ }
+
+ while (dst_ptr < dst_end_ptr)
+ {
+ DATA32 tmp;
+ DATA8 a, r, g, b;
+
+ a = A_VAL(src_ptr);
+ if (!a) { src_ptr++; dst_ptr++; continue; }
+ if (a == 0xff)
+{
+MULT_COLOR(R_VAL(dst_ptr), R_VAL(src_ptr), R_VAL(&mul_color),
tmp);
+MULT_COLOR(G_VAL(dst_ptr), G_VAL(src_ptr), G_VAL(&mul_color),
tmp);
+MULT_COLOR(B_VAL(dst_ptr), B_VAL(src_ptr), B_VAL(&mul_color),
tmp);
+src_ptr++; dst_ptr++; continue;
+}
+ MULT_COLOR(r, R_VAL(src_ptr), R_VAL(&mul_color), tmp);
+ BLEND_COLOR(a, R_VAL(dst_ptr), r, R_VAL(dst_ptr), tmp);
+ MULT_COLOR(g, G_VAL(src_ptr), G_VAL(&mul_color), tmp);
+ BLEND_COLOR(a, G_VAL(dst_ptr), g, G_VAL(dst_ptr), tmp);
+ MULT_COLOR(b, B_VAL(src_ptr), B_VAL(&mul_color), tmp);
+ BLEND_COLOR(a, B_VAL(dst_ptr), b, B_VAL(dst_ptr), tmp);
+
+ src_ptr++;
+ dst_ptr++;
}
}
#endif
@@ -151,52 +176,78 @@
{
DATA32 tmp;
DATA8 a, aa;
-
-aa = (A_VAL(src_ptr) * (A_VAL(&mul_color) + 1)) >> 8;
-if (aa) /* hmmm - do we need this? */
- {
- a = _evas_pow_lut[aa][A_VAL(dst_ptr)];
-
- BLEND_COLOR(a, R_VAL(dst_ptr),
- R_VAL(src_ptr), R_VAL(dst_ptr),
-
[E-devel] Alpha Blending (from: Evas patches -- 2)
> > > 1) Replace the current formula for the new destination > > > alpha (when blending to rgba) by the formula > > > BLEND_COLOR(a, A_VAL(dst), 255, A_VAL(dst), tmp) > > > where "a" is the relevant alpha value. > > > > i tried this and tested it - it is, in fact, wrong :( sorry - the > > math doesn't > > work you as you want it to - i actually tested it and the results > > were - well > > catastrophically bad in terms of rendering display :( i can't put > > this in :( > > That's odd... I'll see if I can take a look at it in more detail > and figure out what's happenning... Well, it has taken some time to look into this as it took me further into things than I'd initially expected ... But I believe that I've found the problem -- it's actually still lurking there in the code recently committed to CVS. I found it very odd that you observed such "catastrophic" results because the difference in the computed alpha values from using the blend-macro vs using the current formula is at most 1, and both give 0 iff the input values are 0. Nevertheless, I thought perhaps an accuracy issue was involved and so took a look at the question of "dividing by 255". I will omit details here, but essentially I found the following: 1) Let's call the "c-ideal", or best approx for color-blending, the formula: DATA8 nc1 = 0.5 + c1 + (((c0 - c1) * a0) / 255.0); for given input DATA8 a0, c0, c1; It turns out that this can be evaluated using integer arithmetic by: DATA32 tmp = (255 * c1) + ((c0 - c1) * a0) + 0x80; DATA8 nc1 = (tmp + (tmp >> 8)) >> 8; If it's any faster, one can rewrite the first statement as: DATA32 tmp = ((c1 << 8) - c1) + ((c0 - c1) * a0) + 0x80; 2) Let's call the "a-ideal", or best approx for alpha-blending, the formula: DATA8 na1 = 0.5 + a1 + (((255 - a1) * a0) / 255.0); for given input DATA8 a0, a1; This too can be evaluated using integer arithmetic by: DATA32 tmp = ((255 - a1) * a0) + 0x80; DATA8 na1 = a1 + ((tmp + (tmp >> 8)) >> 8); We may compare the currently used blend-macro formulas with the "c-ideal" for color-blending, and we find that it differs from it for 1,938 cases. For alpha-blending, using the blend-macro (as proposed in the patches) differs from the "a-ideal" for only 24 cases, whereas the formula a1 + (((255 - a1) * a0) / 255) that is currently used, differs from the "a-ideal" for 21,770 cases. Now, from the formulas for all of these, it is clear that for both the color and alpha components, the computed values from any of these differ by at most 1, ie. the absolute value of their difference is 0 or 1. Also, the computed alpha value na1, is 0 iff a1 = a0 = 0, for all of these. From these facts, one would expect that, visually, the difference between using any of these would be difficult to notice, with say one or two blendings, for most common types of images. Now, to the heart of the matter: I wrote functions for doing rgba to rgba blending with the following five different methods: A) For the color components: the int-arith formula in 1) for the "c-ideal". For the alpha component: the int-arith formula in 2) for the "a-ideal". This is the "ideal". B) For the color components: the current blend-macro. For the alpha component: the int-arith formula in 2) for the "a-ideal". C) For the color components: the current blend-macro. For the alpha component: the current blend-macro used to compute alpha (as in the patches). So this corresponds to what was in the Evas patches (and in the Imlib2 patches as well). D) For the color components: the current blend-macro. For the alpha component: the formula a1 + (((255 - a1) * a0) / 255) ie. The current blending function in CVS. E) For the color components: the formula c1 + (((c0 - c1) * a0) / 255) For the alpha component: the formula a1 + (((255 - a1) * a0) / 255) This one just for completeness. I ran a variety of tests using each of the above, blending a variety of images (with alpha) together 2^n times, for n = 0 to 8, in various associative combinations, from one to 4 layers deep..., and I'll be dammed if I could see any significant difference in the results at all, much less anything that could be considered as radically different. This led me to believe that you had done something wrong in writing down the implementations of the functions, I checked the patches I s
Re: [E-devel] Brainstorming: SWF,Perl and Evas
On Mon, 12 Apr 2004 12:37:58 +0900 Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]> writes: > On Sun, 11 Apr 2004 04:26:25 -0700 (PDT) Ogla Sungutay > <[EMAIL PROTECTED]> > babbled: > > > > similarities? Could they be used together, like say > > Ecore-SWF? > > technically- yes - but evas for example lacks matrix transforms, > splines, radial > fills, and several other "required" things. fonts are done > differently to flash > where last i checked it did them from the spline/curve/line > primitives directly, > and not via ttf's etc. with a LOT of effort i guess all this could > be added and > an E based SWF viewer/player would be possible - but for now i don't > really see > a need and don't have time myself. also implementing all of these > things is no > trivial task - well not trivial to make it FAST and still look good. > Indeed. It's not too difficult to write these things.. *But*, to write them accurately enough so things look good, and do this FAST.. that's not so easy. > . > > 4. Considering we have Beziers, any thoughts on SVG > > rendering? > > we'd need bezier curve clipping (ie render image, other > object/primitive clipped > to a bezier curve path) in fact we really need arbitrary clipping - > ie clip the > rendered output of lets say gradients, lines, polys, images to any > other of > these in the most optimal way (or any combination of these ie an > image scaled > and blended to a dest,m but clipped to another image mask that is > scaled > differently, and this mask is clipped to a polygon that is clipped > to a bezier > that is clipped to a text glyph output.) you get the idea - this You really only need to implement multiplication of pixels to have the core for this (or at least, multiply pixels by alpha pixels)... But then you'd still need a good way to organize this into a workable set of interfaces.. > is very > useful. can be used for making "textured text" ie text font with > some coloured > texture in it - take an image as th texture, clip it to the font - Textured text!! Oh NOW you want textured text! > bingo. this > hasn't been done yet due to simplicity and optimization reasons. > long before > that it wasn't done due to opengl not fully supporting pbuffers for > a long time. > also i want to support some filter methods. particularly "Blurring" > of an object > prior to composting. doing this fast in software is had - doing it > fast with > opengl is also hard. this would let us easily do soft drop shadowed > text with > much less overhead. it will allow all sorts of other effects like > fading in > whiles going from massively blurred to clear and sharp etc. this is > definitely > on my "some time" plan... that and clipping are right near the top > Sounds good! How about bump-mapped textured text :) --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ enlightenment-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Brainstorming: SWF,Perl and Evas
On Tue, 20 Apr 2004 13:36:36 +0900 Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]> writes: > On Tue, 13 Apr 2004 03:34:30 -0400 Jose O Gonzalez > <[EMAIL PROTECTED]> babbled: > > > > technically- yes - but evas for example lacks matrix transforms, > > > > splines, radial > > > fills, and several other "required" things. fonts are done > > > differently to flash > > > where last i checked it did them from the spline/curve/line > > > primitives directly, > > > and not via ttf's etc. with a LOT of effort i guess all this > could > > > be added and > > > an E based SWF viewer/player would be possible - but for now i > don't > > > really see > > > a need and don't have time myself. also implementing all of > these > > > things is no > > > trivial task - well not trivial to make it FAST and still look > good. > > > > > Indeed. It's not too difficult to write these things.. > *But*, > > to write them accurately enough so things look good, and do this > > FAST.. that's not so easy. > > oh god its DEAD simple to write them if you follow "computer science > principles" > you learn in school. you write a wonderfull transform pipeline, > pixel selector > and sampler each generic allowing you to sample an arbitrary > polygonal area > (generally 4 sided) from a source and gain 1 output pixel value, > this extends to > scaling up and down if done right. you can do scaling, rotation > shearing, > stretching and all - but.. here is the but - and what u don't learn > a lot of "at > school" - the PERFORMANCE SUCKS. you have written beautiful simple > code thats > maintainable - and it runs like a dog. its unusably slow. sure in 20 > years your > cpu may be fast enuf for it to be "cool" but you want that TODAY... > and THATS > the problem. writing things to be fast TODAY on a cpu AND also work > on gfx > acceleration chips... :) doing things fast means cutting corners - > lots of them, > and making assumptions :) > I had an even "easier" method in mind -- use straightforward mathematics with real-numbers and analytic methods.. Unfortunately, my machine seems to go into an un-documented "slow-motion" mode whenever it sees the words 'float' or 'double' in code... Yeah, maybe in 20 years or so... > > > . > > > > 4. Considering we have Beziers, any thoughts on SVG > > > > rendering? > > > > > > we'd need bezier curve clipping (ie render image, other > > > object/primitive clipped > > > to a bezier curve path) in fact we really need arbitrary > clipping - > > > ie clip the > > > rendered output of lets say gradients, lines, polys, images to > any > > > other of > > > these in the most optimal way (or any combination of these ie an > > > > image scaled > > > and blended to a dest,m but clipped to another image mask that > is > > > scaled > > > differently, and this mask is clipped to a polygon that is > clipped > > > to a bezier > > > that is clipped to a text glyph output.) you get the idea - > this > > > > You really only need to implement multiplication > > of pixels to have the core for this (or at least, multiply pixels > > by alpha pixels)... But then you'd still need a good way to > > organize this into a workable set of interfaces.. > > the problem here is to do this efficiently. for example if only a > small image is > cliped by a large one - u dont want to render the large image into a > "clip" > buffer mask first then only use part of it > if that clip is shared between multiple objects u don't want to > re-render the > clip mask too. you also want to avoid needing a clip buffer/mask at > all in the > case of being clipped by rectangles or polygons where the clip shape > and values > are easily calculated as spans... :) now combine this efficiently... > tough tough > tough. the solution all windowing system use is "let the app deal > with it" ie - > they dont try and optimise - they simply blindly do what an app > tells them in > terms of using masks and buffers and the dumber the app, the slower > it is. i > want to do it so the app doesn't have to be smart :) that makes life > hard :) > At the lowest level, this can be made fairly efficient -- For each pair of evas objects A and B, write a function for drawing A clipped by B
Re: [E-devel] Brainstorming: SWF,Perl and Evas
> > At the lowest level, this can be made fairly efficient -- > > For each pair of evas objects A and B, write a function for > drawing > > A clipped by B (onto a dst image), as efficient as possible. > > Since 'A clipped by B' equals 'B clipped by A', one'd > > need n(n + 1)/2 functions, where n = num-of-evas-objects. > > aaah but what about: > > A clip B clip C clip D > > A is image > B is rect > C is rect > D is polygon > > we can actually do this clip with NO intermediate buffers, but what > you have > requires an intermediate buffer in each stage. we need to > intelligently punch > through clips until you NEED a buffer. the problem here becomes - > clip buffer > management. when a clip buffer is simple (a n image, not scaled > etc.) there is > no point to make a buffer - simply use the the original. but now > lets say you > want to clip by a SCALED image - but the same scaled image is used > to clip > multiple objects - u dont want to go rescale it every time > so u need to intelligently manage this as a clip buffer > > i think u can do it by generating a clipped "scanline" then > recursively applyign > the clip transforms > but you first need to generate a minimal scanline... :) anyway - > doing this fast > and efficiently and intelligently isnt a walk in the park :) > > > Now, if you want multiple clipping: A clipped by B, > > clipped by C, ... -- then it may depend on just how this 'exists' > in > > the lib.. ie. how many objects can be 'set' as a clipping object > > at a time, etc.. Ultimately, it seems you're going to need image > > buffers of some type if you want complex lists/iterations of this > > sort of thing.. > > it's unlimited. u can clip by as many objects as u want :) and yes - > i will > ultimately need a buffer of some sort... its managing these > pre-calculated clip > mask buffers that is where the pain lies I see. Well, if you want this kind of generality then it can be done with one function -- with the input object, that's to be clipped by the others, considered as a new first or last such on the list.. But, it won't be as fast for most cases... so it may be best to keep faster, special case functions, as you have now. Setting aside the question of clipping by transformed images and how to best cache such ... the basic way I see of doing this is as a generalization of the polygon drawing algorithm. First, intersect all the clip rects to get a minimal such. Then, intersect the bounding rects of the clip images with the above. Next, get a bounding rect for the clip polygons (I'd suggest that the polygon structure keep such bounds data, it can be easily updated whenever a vertex is added/deleted) and intersect with the previous, etc ... So we now have a minimal bounding rect to work from. Now, we need to intersect the polys -- do this scanline by scanline, as you suggest, getting active edges for each clip polygon and the spans given by intersecting the left-right edges with the bounding rect (for aa-polys this is a little more involved but not a problem), when an edge intersects a span and it's aa, then it has to be carried along as part of the state. Do this over the list of clip polygons, intersecting spans as we go along, and thus obtaining a minimal set of spans (plus possibly aa edges) on that scanline. Finally, start computing the alpha/color multiplications of the clip masks/images (and of the polys' edges -- if aa) over each span and 'draw' the result to the dst image.. either point by point or by allocating rgba-spans and using the appropiate blending function. I've neglected gradients, lines, text, and ellipses, from the discussion... But things like gradients we can get the pixels by either actually mapping them or 'vitually' doing so.. Text objects are glyph alpha masks.. Ellipse objects would be handled much as polygons, and similarly for line objects. But yeah, I think it's quite doable :) > > i'd love to see these features eventually: > Just a few things, eh? :) :) > * "thick" options for line objects > * polyline objects > * filled spline objects > * circle/oval/ark objects > * outline options for rect, poly, spline and circle objects > * video objects (can load .mpg, .avi files, spool files or streams > themselves) > * gradient object enhancements to be able to do more advanced > gradients (not > just angle, but endpoints, radial gradients etc.) What are "endpoints"? > * anti-alias options for all vector objects > * right-to-left text handling for text objects > * paragraph objects (can handle full paragraph formatting for all > languages > (left-to-right, top-to-bottom languages like hebrew, arabic, > chinese, japanese > etc.) so u can do multiple lines, wrapping etc. all properly for the > language > * fontset handling > * greymap pre-rasterised font support (to avoid massive .ttf files > for large > charset languages) I
Re: [E-devel] e16.7-pre1 problems
On Mon, 03 May 2004 23:07:24 +0200 Kim Woelders <[EMAIL PROTECTED]> writes: > Jochen Schroeder wrote: > > 1st: > > sometimes the font on top of the window titlebar doesn't display > > properly, see the mozilla titlebar in this picture > > http://pap093.uni-muenster.de/~jschrod/e16fontprob.jpg > > This usually happens after dragging the window across to another > virtual > > desktop. I'm using a modified Phlat theme and couldn't reproduce > this > > with Brushed metal tigert, so it might be a problem with the > particula > > font of that theme. It is very minor anyway. > > > I'm aware of this one. It happens when imlib2 renders on a partially > offscreen window (offscreen left or top only). I suspect it is a bug > in > imlib2 but I could be wrong. > I once experienced a similar sounding problem with some things I was doing with imlib2. I found that I had to make some minor changes to the api.c function "imlib_copy_drawable_to_image" in order to cure what I was experiencing. I've attached a file that contains that function with the changes I'd made. If you're feeling bold and reckless, replace the current function with the one in the attached file, recompile imlib2, and see what happens... it may cure your problem as well, or do nothing, or ... jose. may_fix Description: Binary data
[E-devel] Imlib2 patches -- 2 : rgbadraw, final vers.
Attached is a final version of the imlib2 rgbadraw work that I've sent recently. Here, I've fixed all remaining issues that I had with polygon drawing/filling and cleaned things up overall. Various further improvements could certainly still be done (assembly versions of the 'span' blending functions, better clipping optimizations, etc.), but for now I will leave this as is. Some of the highlights of this work: 1) Aliased/anti-aliased versions of all geometric figure drawing/filling, with all blending ops. 2) Fast, correct, C implementations of all image blending and figure blending 'span' functions. 3) Fast, integer-based figure generating functions, with good visual quality (the blending to dst images can be made faster by writing suitable assembly versions of the 'span' funcions). 4) More modular re-structuring of files for easier maintenance, further improvements, other implementations, etc. 5) Has been extensively tested and checked by a large team of MS "software engineers" !! From 5, it follows that nothing here has been tested or checked in any real way, so you're on your own if you want to try any of this.. but feel free to do as you wish with it :) jose. PS. No diffs are included, only the source files. imlib2_rgbadraw_final.tgz Description: Binary data
[E-devel] Imlib2 patches -- rgbadraw_final_diffs
Attached are diffs against the current CVS for the "final" set of fixes in the imlib2 rgbadraw work I sent recently. It has three files, "blend_c.diff", "ellipse_c.diff", and, most importantly, "polygon_c.diff". The blend.c diff only re-indents things there, for when I happened to look at it, I was surprised to see how bad the thing looked. jose. rgbadraw_final_diffs.tgz Description: Binary data
[E-devel] Imlib2 patches -- 3 -- grad.c
Attached is a quick patch for imlib2's "grad.c" file.. It fixes some things I noticed there while re-familiarizing myself with evas/imlib2's gradients. This (very quickly done) patch fixes: 1. blending with the ADD/SUB/RE ops when the dest image has alpha. 2. the op ADD case was set to do a BLEND_SUB in both the rgba and hsva gradient draw functions. Also: 3. added tests for memory allocation of the hlut/vlut tables. 4. removed several unused variables from these functions. 5. as the code for both functions is moderately long but only differ by *one* line, I've setup most things as macros. This file really needs to be rewritten, as it still does not handle the cases when the blend context is set to 0, and it could benefit a lot from optimizations. Unfortunately I haven't the time right now to do this justice, so for now at least it blends correctly :) jose. grad_c.diff Description: Binary data
Re: [E-devel] font rendering in evas
On Wed, 15 Sep 2004 09:08:51 +0900 Carsten Haitzler (The Rasterman) writes: > On Tue, 14 Sep 2004 14:13:45 +0200 "Nemec, Bernhard" babbled: > > > > 1. glpyph caching, > > > > Doesn't the cache work automatically for any used font size? > > per font size instance there is a glyph cache - BUT now i'd need to > handle per > size AND transform (scale h AND v). i'd either need a glyph cache > per one of > these or change the glyph hash key to include the transform (scaling > factors). > the REAL problem here is the fact that truetype doesn't always like > to scale > linearly as u'd like - it may want to round off/align itself to a > particular > pixel boundary and so the text layout you chose before wont > necessarily match :) > > > > 2. horizontal and vertical scaling may not > > > match. > > > > Addressed in the attached draft. > > > > > 3 - simplicity, 4. almost never happens unless the viewport of > > > the evas and the > > > actual window are not 1:1 scaled. > > > > So, no reason preventing me from doing it :-) > > Comments on the attached draft are much appreciated. Especially > the new > > invocation > > of evas_common_font_load() may not be the smartest way of doing it > (?). > > true - font loading each time would be expensive :) > > > BTW, I'm using this for printing, hence the buffer engine. > > true true :) though evas was never designed for printing - it is > capable in > design/theory of doing it :) > The buffer engine's font scaling code is slightly borked anyway -- has been fixed in some secret work somewhere.. jose. --- This SF.Net email is sponsored by: thawte's Crypto Challenge Vl Crack the code and win a Sony DCRHC40 MiniDV Digital Handycam Camcorder. More prizes in the weekly Lunch Hour Challenge. Sign up NOW http://ad.doubleclick.net/clk;10740251;10262165;m ___ enlightenment-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] font rendering in evas
On Wed, 15 Sep 2004 14:33:12 +0200 "Nemec, Bernhard" <[EMAIL PROTECTED]> writes: > > The buffer engine's font scaling code is slightly borked > > anyway -- has been fixed in some secret work somewhere.. > > > > Can you enlighten me on this? I don't see any difference to > the x11 engine, for example. > > Bernhard > For one, it's incorrectly setting the tmp image's color -- should be set to 0 (as the x11 engine does). But there are other potential problems with it, as indeed is also the case for the other engines, in its use of a new tmp context which only sets the context color, as there are potential uses of the clip, etc.. jose. --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php ___ enlightenment-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
RE: [E-devel] font rendering in evas
> On Wed, 15 Sep 2004 14:33:12 +0200 "Nemec, Bernhar" writes: > > > The buffer engine's font scaling code is slightly borked > > > anyway -- has been fixed in some secret work somewhere.. > > > > > > > Can you enlighten me on this? I don't see any difference to > > the x11 engine, for example. > > > > Bernhard > > > > For one, it's incorrectly setting the tmp image's color -- > should be set to 0 (as the x11 engine does). > But there are other potential problems with it, as indeed > is also the case for the other engines, in its use of a new > tmp context which only sets the context color, as there are > potential uses of the clip, etc.. > > jose. > Well that was utterly confusing.. Now, that I've managed to get some sleep, let me see if I can clear up any confusion I may have caused here. First, it's not that it's not setting the image pixels to 0 that is a problem -- they could be set to anything so long as the pixels have alphas = 0. The problem is that the buffer engine's current means to do this, ie. setting them to dc->col.col & 0xff may not actually set the alpha component to 0 on some machines -- or at least that's my concern with it. Ok, as to the "other potential problems".. As far I can see, there are no actual 'problems' with the rest of the code for this, in any of the "common" based engines. The 'problems' I was referring to were in fact caused by my own borked memory, and way too little sleep in the last few days.. I remembered that when I first went over this part of the evas code, I was concerned about possible un-initialized variables in the newly created context, and I also remember that I ended up doing something with the context clip, but couldn't recall exactly what. So, I just went over what I have and: no, there were no problems with un-initialized variables -- this had been very succintly taken care of by the use of the calloc function -- and what I did was simply to add a small optimization (when there's some clipping to be done) by using a suitable clip derived from the input context clip, that I passed to the new context that the font drawing function uses, ie. set clx' = (ow * (clx - x)) / w; clw' = 1 + ((ow * clw) / w); etc. This limits the amount of text that gets drawn to the tmp image to that which will actually get scaled to lying within the context clip rect. But it's just an optimization issue, not a problem with the current code's correctness. Hope that makes more sense :) --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php ___ enlightenment-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] The E of E
As only a simple observer, lately busy with prior comittments but trying to inch my way free in order to possibly contribute something or other to E, I found the following interesting piece in a certain nefarious website: "In other things I recently read Seth's Blog (http://www.gnome.org/~seth/blog/xrendering) on improved Xrendering for GNOME... " So, I followed that link and read there.. and somehow was also lead to another link http://log.ometer.com/2005-02.html and read some stuff there as well... And, after attempting to digest it all.. I found myself asking: What the hell are these people saying..? What does it mean..? and also: Just exactly what does GNOME (or KDE) 'have' that E doesn't, and conversely..? --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] The E of E
On Tue, 22 Feb 2005 17:04:24 +0900 Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]> writes: > On Tue, 22 Feb 2005 02:45:37 -0500 Jose O Gonzalez > <[EMAIL PROTECTED]> babbled: > > > > > As only a simple observer, lately busy with prior > > comittments but trying to inch my way free in order to > > and i've been adding evas objects too (textblock) just to make life > more fun for > you :) > Ahhh.. and something simple too.. text/fonts related :) > > possibly contribute something or other to E, I found the > > following interesting piece in a certain nefarious website: > > > > "In other things I recently read Seth's Blog > > (http://www.gnome.org/~seth/blog/xrendering) on improved > > Xrendering for GNOME... " > > > > So, I followed that link and read there.. and somehow > > was also lead to another link http://log.ometer.com/2005-02.html > > and read some stuff there as well... > > > > And, after attempting to digest it all.. I found myself > > asking: > > > > What the hell are these people saying..? What does it > mean..? > > > > and also: > > the summary of much of it is "we are moving to a rendering system > that doesn't > just draw - but composites with alpha blending and scaling and image > filters and > effects" - i.e. - evas/edje - what we already have. and "oh we are > going to do > it hardware accelerated - but no good software fallbacks" - i.e. > evas + gl > engine - just no software eninge. > "oh we are going to be able to do all sorts of funky themes and > effects now" - > err.. == edje. everything they talk about as > amazing/new/groundbreaking... we > have done. :) well most of it :) "lets build our widget set on top > of a canvas > object system" - EWL anyone? :) for everything they talk of.. we are > already > there... pioneering it - quietly in a corner :) > Ummm... That does seem to be the thrust of it.. though there was also mention of a "window-compositing manager" -- which of course has nothing to do with E. But somehow, it sounds like so much more..? There was this quote though from the second link: "..Everyone is working on the ability to do OS X or Enlightenment style effects.." Maybe you should take take a few minutes sometime and *write down* your ideas and some details on them.. some diagrams and stuff, etc. :) > > Just exactly what does GNOME (or KDE) 'have' that E > doesn't, > > and conversely..? > > they have apps, communities, publicity and big, mature toolkits and > everyone > thinks they are trying to "kill microsoft" so they all rally behind > them. > Ok. But, the apps and stuff may follow from a 'mature toolkit'.. So what is it about their toolkits that is so much more 'mature'? Who out there would like to spell this out in detail -- What do the EFL's need in order to be as 'mature'? --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Re: The E of E
> On Tue, 22 Feb 2005, Andreas Volz wrote: > > > Am Tue, 22 Feb 2005 04:06:54 -0500 schrieb Jose O Gonzalez: > > > > > > they have apps, communities, publicity and big, mature > toolkits and > > > > everyone > > > > thinks they are trying to "kill microsoft" so they all rally > behind > > > > them. > > > > > > > > > > Ok. But, the apps and stuff may follow from a 'mature > toolkit'.. > > > So what is it about their toolkits that is so much more > 'mature'? > > > > > > Who out there would like to spell this out in detail -- > > > What do the EFL's need in order to be as 'mature'? > > > > One reason (but not the most important) for me to use GTK+ for > > programming is MS-Windows support. Many peoply (including me) > don't use > > MS-Windows, but *many* others do! So portability (not only for > UNIX like > > systems) is a important thing. How portable is the EFL? Does it > run > > (without X-Server) on OSX or MS-Windows? These are the questions > for me > > to be a 'mature' toolkit. So, 'maturity' of the libs consists of, at least: 1. Portability across platforms/os. What else? What about the 'maturity' of the libs in terms of capabilities, functionality, etc? What I personally would like to see - as an 'academic' exercise lets say - is a fair description of just what common libs/components it takes to make up something like GNOME or KDE.. A "blueprint", if you will, for what makes up something like a basic 'desktop environment'. --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Re: The E of E
> > > they have apps, communities, publicity and big, mature toolkits and > > everyone > > thinks they are trying to "kill microsoft" so they all rally behind > > them. > > Ok. But, the apps and stuff may follow from a 'mature toolkit'.. > So what is it about their toolkits that is so much more 'mature'? > > Who out there would like to spell this out in detail -- > What do the EFL's need in order to be as 'mature'? > > Well, we now have that 'maturity' of the libs consists of, at least: 1. Portability across platforms/os. 2. EWL needs more widgets - to the point where it has the same complement of widgets you see in qt and gtk+. they need to be fast and rock-solid. stable. it needs to support right-to-left languages for text and much better text layout. it needs more documentation and examples. Someone has already expressed interest in working on 1. The question then is - Who out there wants to work on 2.? Who wants to help with the work of finishing the "next generation toolkit" that is, in fact, already here -- ewl. Anything else the efl's need? > What I personally would like to see - as an 'academic' > exercise lets say - is a fair description of just what common > libs/components it takes to make up something like GNOME or KDE.. > > A "blueprint", if you will, for what makes up something like > a basic 'desktop environment'. > Ummm... --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Evas Blending Fun
Attached are some blending routines for evas.. mostly useless to anyone except for Carsten to probably laugh at :) Very sketchy stuff, just for testing some ideas etc. Evas.tgz Description: Binary data
Re: [E-devel] Evas Blending Fun
On Fri, 15 Apr 2005 17:18:26 +0900 Carsten writes: > On Wed, 13 Apr 2005 07:07:46 -0400 Jose O Gonzalez > <[EMAIL PROTECTED]> babbled: > > > > > Attached are some blending routines for evas.. mostly > useless > > to anyone except for Carsten to probably laugh at :) > > Very sketchy stuff, just for testing some ideas etc. > > i actually cant even compile some of them - assembler is not happy. > its not happy with some of the macros being used as assembler macro > parameters - it was a normal everyday variable there - not a macro. > if i create a tmp variable it still fucks up... lots of them. have u > tried it yet? i have hacked around some - but others dont work no > matter how hard i try (the compilers own optimisations etc. are > fucking around with the mmx) > Yeah, I was worried that the C macros being passed to the mmx macros might cause a problem, so I did try compiling them first. For me they all compiled cleanly, so I didn't worry about it further.. But I only actually tested *one* function (blending pixels to pixels.. it seemed to work fine). Here are the CC flags I used in my test makefile: CCOPTIONS = \ -D__i686 \ -02 \ -funroll-all-loops \ -malign-loops = 2 \ -malign-jumps = 2 \ -malign-functions = 2 \ -ffast-math \ -Winline \ -g I never did test any of the other functions, nor did I try compiling or testing evas with them, at all. In any case, if it doesn't compile for you with evas' given options, then it's no good :( --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas Blending Fun
On Fri, 15 Apr 2005 17:18:26 +0900 Carsten writes: > On Wed, 13 Apr 2005 07:07:46 -0400 Jose O Gonzalez > <[EMAIL PROTECTED]> babbled: > > > > > Attached are some blending routines for evas.. mostly > useless > > to anyone except for Carsten to probably laugh at :) > > Very sketchy stuff, just for testing some ideas etc. > > i actually cant even compile some of them - assembler is not happy. > its not happy with some of the macros being used as assembler macro > parameters - it was a normal everyday variable there - not a macro. > if i create a tmp variable it still fucks up... lots of them. have u > tried it yet? i have hacked around some - but others dont work no > matter how hard i try (the compilers own optimisations etc. are > fucking around with the mmx) > Well, here's another possibly fruitless variation of the sketchy, problematic, evas mmx blending functions -- this time without compound logical or arithmetic expressions passed to the mmx macros. All the functions compile cleanly for me.. and the ones I've tested 'seem' ok.. but things did so before as well, so if things are still screwed up on your system, there's no telling what's going on without looking further into it -- and I'm not sure it's really worth it :) evas_blend.tgz Description: Binary data
[E-devel] Where is the e "wish" list?
I have a 'wish' for things I'd like to see in e.. not in e the wm, there are enough wishes for things in there already :), but in e as in the efl's. Two specific things to be exact: 1. A general purpose "list/hash" lib. 2. A general purpose "file" lib. The code for such functionality is currently in existance in various of the efl libs, in various degrees of similarity, capabilities, etc. Can a common concensus be reached on an api for 'lists/hashes', and have that placed into its own lib as a core requirement for the efl's? Same for basic 'file' handling functionality? Any thoughts? --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Where is the e "wish" list?
Therein lies part of the problem.. evas should not depend on ecore. If one wants to write some lib that needs list/hash/file handling, then one is faced with: a. link with evas and use its list/hash routines, and something else for file handling, possibly ecore's.. b. link with ecore and use its list/hash/file routines.. c. something else. It would be best if both evas' and ecore's list/hash routines (and evas' internal file handling routines) came from common sources they both linked to.. or, list/hash and file 'modules' they both could load. Suppose one were to write an immediate-mode graphics lib say, and I want to have its rendering routines to be the 'same' as the ones used for evas - ie. given as common loadable modules, and further, they both used common image loading, font loading, and possibly other types of common modules. What list/hash/file routines could one use for these common modules? Can Ecore_Data and Ecore_File exist as separate well-known, loadable modules that one could load without linking to all of ecore? On Sat, 11 Jun 2005 11:25:03 -0400 dan sinclair writes: > Well there already exists lists and hashes in Ecore_Data and > Ecore_File > should handle the file handling. There are slightly separate list > data > structures in evas but that was done so evas dosen't depend on > ecore. > > dan > > > On Sat, 2005-06-11 at 08:10 -0400, Jose O Gonzalez wrote: > > I have a 'wish' for things I'd like to see in e.. > > not in e the wm, there are enough wishes for things in > > there already :), but in e as in the efl's. > > > > Two specific things to be exact: > > > > 1. A general purpose "list/hash" lib. > > > > 2. A general purpose "file" lib. > > > > > > The code for such functionality is currently > > in existance in various of the efl libs, in various > > degrees of similarity, capabilities, etc. > > > > Can a common concensus be reached on an api > > for 'lists/hashes', and have that placed into its own > > lib as a core requirement for the efl's? Same for basic > > 'file' handling functionality? > > > > Any thoughts? > > > > --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] OUTBUF_DEPTH_BGR_32BPP_888_8888 support in buffer engine
On Thu, 23 Jun 2005 14:41:31 -0500 Nathan writes: > I think this would fall in the category of clipping to arbitrary > objects. Personally, I'd love to see this added as it would make > some > interesting effects easier to implement, but it's certainly not > trivial and could have a performance impact. > > Right now clipping is restricted to rectangles, so the clipping > color > is applied through blending a single color with the clipped pixels. > To > do arbitrary clipping it would require rendering the clipping pixels > to a buffer, then blending the clipping pixels with the clipped > pixels. Another option is providing a clipping operation for each > primitive to perform the clip/blend operation. > One has to "clip" all the clipping pixels to a buffer and then "clip", not blend, the clipping pixels to the clipped ones, then blend the result to the buffer used internally by the engines to accumulate pixels. To "clip" one pixel by another, in argb format say, one multiplies the color components of one by the other's. The main reason this hasn't been done in general is due to the need to set up an internal mechanism for doing this *efficiently* -- for all types of objects, with any number/type of clip objects (and eventually, implementing it efficiently with all the engines). > On 6/23/05, Jason Tackaberry <[EMAIL PROTECTED]> wrote: > > On Thu, 2005-06-23 at 11:24 +0900, Carsten Haitzler wrote: > > > read it - fixed it up a bit (used copy functions as this will > use mmx/sse > > > functions if available) :) > > > > Great! Tested and works. With this and the evas_free() fix I'm a > happy > > camper. > > > > One of the main things I'm missing from evas is some method to > cause > > text to fade out, rather than cropping it abruptly (or using an > > ellipsis). I suppose what I want is a way to use a gradient > object as a > > clip for a text object. With pyimlib2 (python bindings I wrote > for > > Imlib2), I just added a custom draw_mask() function, which applies > the > > luma of one image to the alpha of another. So I create a gradient > of > > white to black, and draw_mask() that to the image containing the > text. > > > > Is there way to do this with evas currently? If not, how > difficult is > > something like this to implement? > > > > Cheers, > > Jason. > > You can cause the text, as a whole, "to fade out" by decreasing the alpha of the color you're drawing the text in. But not in the manner that you seem to have in mind here, ie. to let some parts of the text fade away, as could occur if it were "clipped" by a suitable gradient say. It's possible evas will have this kind of capability "soon" ... --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
