While I'm around here wishing Jorge a happy birthday, now seeing this
flurry of controversy...
David Seikel wrote:
> We have a fundamental disagreement about the need for changing
> something that works quite well. Does not sound like any of us are
> gonna change the minds of the others.
>
Carsten Haitzler (The Rasterman) wrote:
>
>> Either way, this would allow for engine-specific extensions
>> for evas.. wrapping things adequately would allow for things like
>> say an "evas3D" lib if really desired.
>
> sure. 3d INSIDE a "3d object" i can deal with in evas :)
>
Exactly. W
Samuel (lok) wrote:
> Mixing iiirk and notification together would provide over 90%
> of what a tray does. Add to that IBar/IBox and you get something
> near OS X dock. Of course any other combination is possible.
What's an "iiirk"?
--
Here's a vision: Vincent wrote:
> While reading an article about gtk+ 3 (from osnews), i have found a page
> about different canvases:
>
> http://live.gnome.org/ProjectRidley/CanvasOverview
>
> and evas is mentioned. Also, i think that there are some errors about
> evas, and some missing stu
Massimiliano wrote:
> > > Might I suggest exporting the efreet xml parser and use it
> > > instead? Does anyone object? Using strstr to parse xml isn't
> > > very nice.
> > >
> > > Sebastian
> >
> > On my side i don't have any preference, i initially wrote my
> > parser 'cause i've to
Dan wrote:
> Currently Ewl positions widgets based on absolute coordinates. This
> works but isn't unnecessarily optional. Thoughts on changing the
> internals of Ewl to use parent relative placement of widgets?
>
> This would, hopefully, simplify some of the container code and allow
>
> >I can't say that I've followed what this is about.. but if
> > it's something like wether "e" should have a good xml parser/api
> > vs. everyone who needs something like that having to write their
> > own... then I'd say it may be time for "e" to stop 'poo-poo-ing'
> > xml (mostly an e
> You can do this now with Ewl. The only problem being, everything
> is absolute coordinates which is a bit strange for this kind of
> widget. If you want to do this, inherit ewl_box, remove configure
> event, add your own configure and use ewl_object_place to put the
> widgets where you wan
> >However you have it (though rel coords would seem best),
> > if you really want ewl to be a flexible tool for building
> > artistic, rich apps, then you'll want a natural way to
> > arbitrarily position child *widgets* - not just evas objects..
> > and to allow for custom kinds of chil
> > >However you have it (though rel coords would seem best),
> > > if you really want ewl to be a flexible tool for building
> > > artistic, rich apps, then you'll want a natural way to
> > > arbitrarily position child *widgets* - not just evas objects..
> > > and to allow for custom kin
Massimiliano wrote:
> > Why write our own when libxml2 works quite well? Seems like
> > needless NIH to me.
>
> The module lives inside E, so i think isn't good to add another
> dependecy for E.
Ah, good man. You've been thoroughly indoctrinated into
avoiding the evil influences of 'depe
Massimiliano wrote:
> 2008/3/20, Jose Gonzalez <[EMAIL PROTECTED]>:
>
>> Ah, good man. You've been thoroughly indoctrinated into
>> avoiding the evil influences of 'dependencies' in 'E', now it's
>> even for e17 modules!
>&g
> > In general I don't have any objections to the addition of size
> > hints to Edje, these could actually be useful to EWL as we could
> > use them in place of some of the existing size hints we get from
> > Edje. I'm not really certain why you want the ability to set the
> > min and max sizes pro
Carsten wrote:
> > >
> > > edje_extern_object_min_size_set()
> > > edje_extern_object_max_size_set()
> > > edje_extern_object_aspect_set()
> > >
> > > these attach hints via a generic data + string key attaching
> > > mechanism so edje can pick them up when swallowing. of course
> > > form
Gustavo wrote:
> anyone really looked at the patch? It says it all :-)
>
>
I saw the patch. But it refers to size 'hints', and still leaves open
the question of obtaining an object's min/max size.
-
This SF.net email
I wrote:
> Gustavo wrote:
>
>> anyone really looked at the patch? It says it all :-)
>>
>>
>>
> I saw the patch. But it refers to size 'hints', and still leaves open
> the question of obtaining an object's min/max size.
>
>
Let me be a bit more precise here:
1) Is it desi
Gustavo wrote:
>> Let me be a bit more precise here:
>>
>> 1) Is it desirable to obtain an object's min/max_size?
>> 2) If it is, then:
>> is it a good idea to have a separate api function to get those values,
>> or do you intend that eg. to obtain the min_size, one should always
>> be
Carsten wrote:
>> via an api func - the object calculates them and gives you those
>> min/max values.. ie. you can *get* such things via an api function.
>> But there's no sense that I can see in an api function to *set* them.
>>
>
> of course there it - smart objects. they need to be able to
Gustavo wrote:
> On Tue, Mar 25, 2008 at 10:39 PM, Santiago Aguiar
> <[EMAIL PROTECTED]> wrote:
> > Hi everyone!
> >
> > I started working with edje yesterday (always a lover of e,
> > but I was amazed in Dave Andreoli's presentation at bossa
> > conference!) and second thing I wanted to do
Gustavo wrote:
> On Wed, Mar 26, 2008 at 10:17 AM, Santiago Aguiar
> <[EMAIL PROTECTED]> wrote:
>
>> I changed the patch to reflect Gustavo's comments.
>>
>> I left the part table lookup to keep the compile time check (besides
>> most embryo wrapper functions do something similar). Would i
Santiago wrote:
> I wrote a patch that does the compile time check of the group name
> when adding a GROUP: tag. Now the part_swallow embryo function
> *requires* the second parameter to be tagged by GROUP: and refer to an
> existing group.
>
> The following patch includes both the part_swal
Gustavo wrote:
> On Thu, Mar 27, 2008 at 1:46 PM, Jose Gonzalez <[EMAIL PROTECTED]> wrote:
>
>>Gustavo wrote:
>>
>> > On Wed, Mar 26, 2008 at 10:17 AM, Santiago Aguiar
>> > <[EMAIL PROTECTED]> wrote:
>> >
>> >> I c
Vincent wrote:
> ..
>>
>> Then go from there and build things like an evas-3D lib if
>> desired.. possibly dependent on gl but able to render to any evas by
>> say rendering to a gl buffer and getting argb data if need be, or some
>> other way..
>
> just to mention that the direct3d eng
andres wrote:
> @notdirectedtoanyoneinparticular:
> Using Edje to theme a constricted widget library like GTK or QT would be a
> complete waste of potential. The only way you will have E, EWL and ETK
> looking *the same* will be creating yet another bland constricted library.
>
> In web desi
andres wrote:
> Ok, my idea would be something like this. Split themes in two,
> a "elements.edj" file and a "theme_ewl.edj", "theme_etk.edj", etc. file.
> I think I covered all the necessary elements (I checked the "test" apps from
> each toolkit) but feel free to extend it as you wish.
>
>
dan sinclair wrote:
> To what end? What's the point of tying them together like this? It would
> be better, in the long run, to just have a single widget library instead
> of 3.
>
>
The 'one true way' of widgetry with the one true mechanism for
theming,
leading to the possibility o
dan sinclair wrote:
>>
>> The 'one true way' of widgetry with the one true mechanism for
>> theming,
>> leading to the possibility of a uniform look&feel for 'all' apps?
>> Maybe. But wether 1 or 3 or 15 widget libs, it's really the
>> one(s) that have
>> apps written for them tha
The recent discussions here about toolkit theming and such
has brought up, to me at least, the question of the future of the
etk gui-toolkit. From what I can see, there has been little or no
work done on this lib in a looong time -- it appears abandoned or
maybe just plain un-maintained righ
Simon wrote:
> Hi guys,
>
> About the current situation of Etk, I don't think I will work on it anytime
> soon
> for several reasons. First of all, for the last months, I haven't really had
> so
> much free time to dedicate to Etk, I have been kept quite busy by a lot of
> things such as scho
Dariusz Knociński wrote:
>> Hi All,
>> I found bug imlib2 library (1.4.1.000) in procedure __imlib_hsv_to_rgb(...),
>> old alghoritm wrong
>> calculate internal values and produces bad result. I wrote new one and
>> actualy testing it. This bug
>> produce black bottom rect in imlib2_colorspa
Cedric wrote:
> Hi,
>
> Let's really break everything ! This is the same serie of old patch
> up to date that improve the cache system. It should not break
> anything. The code is cleaner and should fix some bugs hard to track
> in the current code base.
>
> I want to base my work on loadin
Cedric wrote:
>> That's a pretty hefty patch. :) Do you think you could write
>> down some of the design/structure/etc, and what you're aiming for
>> here.. for the sake of posterity and mere mortals with little time
>> to look it all over. :)
>>
>
> Yes of course. So it's basica
>> Thanks. :) Actually, I do have several things I was thinking
>> about on this, but let me just mention a kind of 'peripheral' thing
>> you brought up - namely, that of "background loading of an image
>> surface".
>> I'm not sure I see what you mean by this - in evas. For local
>
Just wondering if any progress has been made on this (eg.
Gustavo, Vincent, ...?), or if anyone from the SoC is planning to
give it a try?
If not, then maybe I'll spend a bit of time to at least get the
ball rolling on this for evas.. at least get image fill-transforms
(affine ones),
Gustavo wrote:
> On Thu, Apr 10, 2008 at 6:00 PM, Jose Gonzalez wrote:
>
>> Just wondering if any progress has been made on this (eg.
>> Gustavo, Vincent, ...?), or if anyone from the SoC is planning to
>> give it a try?
>>
>
> I haven'
Gustavo wrote:
>>> Well, what we've discussed at BossaConference, raster, cedric and
>>> others might complement/correct me here: add a mechanism similar to
>>> clip as it would accumulate various filters (so rotation + shear + ...
>>> will look fine). Make a function available for the filter t
I wrote:
>> However, as I said, I have no time to work on this ATM, so if you like
>> to try an alternative approach, please do it. Keep it as a branch
>> somewhere and share your results, someone may test it and see how well
>> it works, maybe it would suffice and this would be integrated,
>>
Cedric wrote:
> On Fri, Apr 11, 2008 at 8:35 AM, Jose Gonzalez wrote:
>
>>I wrote:
>> >> However, as I said, I have no time to work on this ATM, so if you like
>> >> to try an alternative approach, please do it. Keep it as a branch
>> >&g
Gustavo wrote:
>> The main difference is that of avoiding the iterative 'clipping'
>> mechanism as the single method for doing everything.
>> What you want is something like: A clips B clips C clips D clips
>> E clips F clips G clips H say, where H is eg. an image obj and G a
>>
I wrote:
>> Of course one could implement F1 as a weird filter that uses fragment
>> shaders to provide a fade-out effect, so eliminating the need for that
>> in clipper.
>>
>
> That is very easy to obtain via (projective) transforms and
> masks (image, grads, or general 'drawing obj
Carsten wrote:
>> But what I was curious about was what exactly you had in mind
>> with your:
>>
>> typedef struct _Evas_Native_Surface Evas_Native_Surface;
>> /**< A generic datatype for engine specific
>> native surface information */
>>
>> EAPI void
>> evas_object_image_native_sur
Gustavo wrote:
> Filters will just be filtered by filters, so it's like
> "SO1(O1->F1)->F2->F3". Object O1 that is filtered by F1 and inside
> Smart Object SO1 that is filtered by F2 that is filtered by F3, O1
> will get these 3 filters.
>Example, F1 could be blur, while F2 be rotation and
>> What do you do if such a native surface is set and one asks
>> for the argb data? What do you do about users setting native surfaces
>> which don't match with the display targets somehow (differing x
>> resources for example).
>> I'd say - restrict native surface api to only have a
I wrote:
>Gustavo wrote:
>
>
>> Filters will just be filtered by filters, so it's like
>> "SO1(O1->F1)->F2->F3". Object O1 that is filtered by F1 and inside
>> Smart Object SO1 that is filtered by F2 that is filtered by F3, O1
>> will get these 3 filters.
>>Example, F1 could be blur,
Gustavo wrote:
>> PS.
>> I'd just set a 4x4 proj transf (you can get some funky curved
>> stuff that way) and have utility functions for generating such in
>> various ways (eg. for obtaining one from four dst points, for
>> composing two transforms, etc.).
>>
>
> Ok, trying to rep
Gustavo wrote:
>> >- 4x4 proj transf => good, one idea that we were considering.
>> >
>>
>> That's very nice for "we". :)
>>
>
> you mean because of me? Or because of others? At least raster, if you
> ask him, he have tons of ideas on how to do things, he have considered
> almo
Carsten wrote:
>>> don't be too excited... it will take time to have someone to do that.
>>>
>> What! I thought you were working on this full-steam ahead..
>> Carsten said that's what you were doing! You're going to have
>> to speak with him about it.. slap him around a bit and thr
Carsten wrote:
>> Anyway... Since you're still thinking about all this, and
>> since this has already been discussed at bossa, I'll drop the issue.
>>
>
> there is always room for input and discussion. until someone actually knuckles
> down and starts doing this, discussion is good a
Dariusz Knociński wrote:
> Patch:
> diff -u -p -r imlib2-1.4.1.000.old/src/lib/color_helpers.c
> imlib2-1.4.1.000.new/src/lib/color_helpers.c
> --- imlib2-1.4.1.000.old/src/lib/color_helpers.c 2007-05-21
> 00:58:01.0 +0200
> +++ imlib2-1.4.1.000.new/src/lib/color_helpers.c 2008-
Gustavo wrote:
>> PS.
>> Some here would like to have ultimately flexible 'filters'
>> defined via some cpu&gpu supported "shading language" (a kind of
>> gfx scripting mechanism), but I seriously doubt that anyone here
>> is going to spend the time and effort required to design and
Ok, let me continue where I left off last time.
We have these various kinds of notions for possible 'filters'
in evas (there are others as well, including ones that might involve
time, ie. animation related ones), but most people here would seem
to want something along the lines of (2
> This is the kind of thing that makes 'chaining' of arbitrary
> filters a problem unless very strict semantic rules are followed,
> and an api used which is able to naturally represent those rules.
>
> I'll continue this a bit later, but please do jump in
> with comments or whatnot
Cedric wrote:
>> In all seriousness if there is love for my idea I commit to implement it.
>> If there isn't, I will be more than happy with Dave's solution.
>>
>
> Their is. It will be a real win if we can just check if an Edje_Object
> really provide all the needed stuff. We could eve
'Mickey' wrote:
>>> We could put checks like this in edje_object_part_swallow. But I can't
>>> help to
>>> think was programmed to work this way for a reason I ignore.
>>>
>> All ELFs are written in this way, without error checking and reporting, i
>> think it's for performance reason an
> So, what kind of api should be provided for 'filters for evas
> objects'? And how can general/loadable such filters be defined and
> obtained?
>
> Gustavo has given one possible suggestion (still needs the
> issue of general/loadable ones addressed, and may want to replace
> the 'set
> PS.
> Here's a distantly related issue though: One of the most common
> things that people want to do with images is to rotate them (possibly
> in a 3D perspective way), flip them, blur them, etc. How can one make
> it easy to express such things for evas image objs (with filters) via
> th
Gustavo wrote:
> On Mon, Apr 21, 2008 at 1:04 AM, Gustavo Sverzut Barbieri
> <[EMAIL PROTECTED]> wrote:
>
>> Jose,
>>
>> I'm running out of time to reply to all of these ideas, I expect to
>> get back some development time after the company I started start to
>> calm down on the "real wo
Gustavo wrote:
>> > Ah, I'd like to write a small prototype of this idea. It would get an
>> > ARGB buffer, get the filters as a linked list/array negotiate buffers
>> > and then process, giving the output as another ARGB buffer to check
>> > the results. Then modify this to add hardware ac
> We've mentioned the semantic interpretation of these 'surface'
> filters acting on an object as _functionally_ equivalent to first
> rendering the object to a buffer 'surface' and having the filter
> act on that surface... Ok, how about we make this former action
> available thru the evas a
Gustavo wrote:
>> PS.
>> This is fairly easy to do right now in evas, except with the
>> gl engine, since one'd need to draw to gl textures and there's no
>> code in evas right now to do that. So, your work on the gl filters
>> stuff could actually be very useful for that (among other
I wrote:
> This wouldn't really have any impact with the use of 'native
> surfaces' - well, depends on how wide the interpretation of such.
> All the engines - with the singular exeption of the gl one - use
> native surfaces to do the rendering to, in one way or another.
>
That
Carsten wrote:
>> I also know that adding any of this to evas is going to
>> mean a fairly large re-working of the image internals (among
>> other things), and that although a general 'filters' mechanism
>> is a very powerful thing, there are many, many aspects here
>> that need to be con
Ok, let me give you some 'criticisms' I have of parts of the
approaches to this filters stuff that both Carsten and Gustavo
suggested, and let me start with:
I just don't see a realistic "need" for having a built-in
mechanism of arbitrary lists of arbitrary filters to be applied
to a
Let me give some further thoughts on your proposed api:
> it should be LIKE the clipping api
>
> filt = evas_object_filter_add();
> evas_object_resize(filt, 200, 200);
> evas_object_filter_effect_set(filt, EVAS_FILTER_CHILDREN_ONLY);
> evas_object_filter_type_set(filt, "blur/gaussian");
>
Gustavo wrote:
> On Thu, Apr 24, 2008 at 3:54 PM, Jose Gonzalez <[EMAIL PROTECTED]> wrote:
>
>> Ok, let me give you some 'criticisms' I have of parts of the
>> approaches to this filters stuff that both Carsten and Gustavo
>> suggested, a
>> I wish someone would point out an interesting, and/or common,
>> real-time gui use of something besides: one specialty filter (say a
>> blur or a bumpmap) followed by a geometric transform (and possibly
>> all clipped by a mask).
>>
>
> in order to do cover flow-like we need:
>
I wrote:
>>> I wish someone would point out an interesting, and/or common,
>>> real-time gui use of something besides: one specialty filter (say a
>>> blur or a bumpmap) followed by a geometric transform (and possibly
>>> all clipped by a mask).
>>>
>>>
>> in order to do cov
Just as a change of pace from the evas filters/transforms stuff...
here's a simple ability that could be useful in evas right now.
There are many, many kinds of custom evas object types one could
define... and some of these might involve using external libs (either
in their implementat
> As we discussed at IRC, probably this policies can be handled on top
> of currently existing Size_Hints and no other members should be added
> to the struct.
>
> Also agreed at IRC is that most difficult part is to get all the
> requirements written, we should start with V/HBox as they're useful
I wrote:
> There's a very simple way to have this ability in evas right,
> one that requires very few internal additions and no modifications
> to any of the current stuff.
>
That should've read "...to have this ability in evas right now,"
Note that this deosn't mean that implem
Gustavo wrote:
>> One of the things I see going on with this kind of thing is
>> an attempt to put more and more 'widgetry/layout' kinds of needs
>> into evas objects in a generic way. The 'problem' with some of this
>> is that evas objects don't have any real notion of 'inheritance' o
Gustavo wrote:
> Hi guys,
>
> As you can see from CVS log, I did some repacking of Evas_Object and
> managed to save more than 80 bytes, almost 1/3 of it is gone.
>
> While some aggressive packing went in, like "layer" number being a
> short now, I'm a bit unsure if applying the attached patch
Gustavo wrote:
>> It was more
>> about having all these things (including some older stuff) that
>> may or may not apply to this or that obj type, no way to know,
>> etc. Ideally a "pie in the sky" kind of thing would be an evas
>> based on an ecore_object 'object' system (with all the ecor
Getting back to the evas filters/transforms stuff...
One other aspect that needs to be addressed has to do with the
very notion Gustavo mentioned about "negotiating" buffer sizes that
a filter/transform might need for putting results to.. and in fact
this also covers things like calcul
Gustavo wrote:
>> One other aspect that needs to be addressed has to do with the
>> very notion Gustavo mentioned about "negotiating" buffer sizes that
>> a filter/transform might need for putting results to.. and in fact
>> this also covers things like calculating update rects when de
Andreas wrote:
> The calculator works nice with edje_editor, but if I open it with
> edje_viewer it doesn't work. What is the preferred way to run
> "self-hosting" edje application?
What's the relevant notion of: "self-hosting" edje application?
> Maybe a plain C application that does
Andreas wrote:
>>> The calculator works nice with edje_editor, but if I open it with
>>> edje_viewer it doesn't work. What is the preferred way to run
>>> "self-hosting" edje application?
>>>
>> What's the relevant notion of: "self-hosting" edje application?
>>
>
> My definiti
Gustavo wrote:
>> >>>
>> >> What's the relevant notion of: "self-hosting" edje application?
>> >>
>> >
>> > My definition of "self-hosting" edje apps is an application that
>> > doesn't need any special C code to work. See the calculator that is
>> > referenced in the starting E-Ma
Carsten wrote:
>> Yeah, and it sounds like a fine 'security minded' approach..
>> but in practice it's not going to make much of a difference since
>> edje is used along with all sorts of code that's highly insecure.
>>
>
> see above. it is important. it's a mistake microsoft have ma
Then one needs to extend edje/embryo scripting far more than
it's currently capable of.. and for it to be sufficiently capable
for general kinds of 'apps' it may need to have access to system
calls and other things. One'd also need to have well-known entry
points
> Note that things like Flash/mxml (then to swf) or Silverlight/
> xaml (may also have some binary representation), unlike edje/edc,
> have extensive 'script' language support and allow for separating
> the code logic from the 'gui' part in separate files if desired
>
Diego wrote:
> Hello all.
> Working with evas+Lines in python, is fast. But if you need a line with more
> then one pixel of width, it gets very slow (in dispositives like N800),
> because object Line dont have width support, so its needen to use Rectangles
> to make it works.
>
> I made a modi
Gustavo wrote:
> Anyone else looked at this? May I add the clipped smart object (no
> layout stuff!) to evas? I can add some docs and even change basic
> smart object to refer to this one for simple implementations.
>
>
For those who are irc challenged, maybe you could give a short
ov
+ * If the requested colorspace is the same as the image colorspace
+ * nothing is done and NULL is returned.
+ if (!o->cur.cspace == to_cspace) return NULL;
To cspace or not to cspace ...
-
This SF.net email is spons
Diego wrote:
> We decided to improve the line implementation to speed up the use of
> evas-lines in python (our case). Yes, we could just use polygons, but we are
> trying to reduce processor usage at this point.
> Its faster to draw lines (with lines implementation) directly, specially
> deali
>>> Anyone else looked at this? May I add the clipped smart object (no
>>> layout stuff!) to evas? I can add some docs and even change basic
>>> smart object to refer to this one for simple implementations.
>>>
>>>
>> For those who are irc challenged, maybe you could give a short
>> ov
Gustavo wrote:
>> It's definitely useful to have such a ready-made simplifying
>> smart-class construction mechanism that could be 'overriden' - and
>> if you could couple that with some kind of object system for smart
>> data it might even be close to some aspects that the gui toolkits
>>
>
> ...
>
>/* I TOLD YOU! this here STOPS the gradeint bugs. it's a missing
> * emms() before doing floating point operations! the thread pipe code
> * just brought it out reliably. i swear i had seen this long before i
> * ever added the thread/pipe code.
> *
> * now here
Carsten wrote:
>>> ...
>>>
>>>/* I TOLD YOU! this here STOPS the gradeint bugs. it's a missing
>>> * emms() before doing floating point operations! the thread pipe code
>>> * just brought it out reliably. i swear i had seen this long before i
>>> * ever added the thread/pipe cod
Carsten wrote:
>>> it's perfectly threadsafe. it has nothing to do with threads. it has to do
>>> with there being no emms called before doing fp ops.
>>>
>> I don't think so. And emms isn't needed there without threads,
>> not when all funcs clean up after themselves. Disable pipe
Gustavo wrote:
> Ok, stop you guys!
>
> I cannot say for sure since I never played with mmx that much, but I
> fear raster is right about that.
>
> as for thread safety, registers do not need special care for threads,
> no locks or other requirements, so yes, it should not have any special
> c
Gustavo wrote:
>> The issue isn't one of safety in the sense of circular
>> referencing, it's mmx/fp 'safety', ie. that we know for certain
>> that the execution paths aren't being interrupted in such a way
>> that although you think you've released mmx registers, and thus
>> the next guy
Gustavo wrote:
>> The issue isn't one of safety in the sense of circular
>> referencing, it's mmx/fp 'safety', ie. that we know for certain
>> that the execution paths aren't being interrupted in such a way
>> that although you think you've released mmx registers, and thus
>> the next guy
Carsten wrote:
> On Sat, 31 May 2008 13:17:42 -0400 Jose Gonzalez <[EMAIL PROTECTED]> babbled:
>
>
>>Gustavo wrote:
>>
>>> I believe it's up to OS to save/restore all the registers when you
>>> change threads. Am I wrong?
>>
Gustavo wrote:
The issue isn't one of safety in the sense of circular
referencing, it's mmx/fp 'safety', ie. that we know for certain
that the execution paths aren't being interrupted in such a way
that although you think you've released mmx registers, and thus
the
I wrote:
>> ..
>> ..
>>
>> the fact that now there was basically nothing between draw calls to guard
>> against fp op safety - as fp ops were not being used mostly, means that it
>> was
>> much more likely u ended up with the cpu in a non emms state before doing fp
>> o
Mats Ekberg wrote:
> Hi Cedric and all others.
>
> I have attached a minimal test case that shows the same behaviour as
> our application code. The image size is set once, but the second time
> (if there has been a rendering in between) the assertion error occurs
> if the new size differs from
Cedric wrote:
> I did some test around this and I think it came from the fact that
> o->dirty_pixels is not set to 1 after the second call to
> evas_object_image_size_set. A quick fix for your example is to call
> evas_object_image_pixels_dirty_set just after
> evas_object_image_size_set. I cur
I wrote:
> Cedric wrote:
>
>> I did some test around this and I think it came from the fact that
>> o->dirty_pixels is not set to 1 after the second call to
>> evas_object_image_size_set. A quick fix for your example is to call
>> evas_object_image_pixels_dirty_set just after
>> evas_object_i
Cedric wrote:
>>> Well, the semantics of the image-size-set function has always
>>> been that if there is no data or file for the image, it will create
>>> data of the requested size, and if there is data (possibly from a
>>> file), it will create new data of the requested size and copy as
1 - 100 of 342 matches
Mail list logo
