Carsten writes:
> the real solution is to know the encoding of the title string
> if it is not already a utf8 one - and convert.
Yes. It's a 'slippery slope' to do otherwise.. one could
argue eg. for having evas convert to/fro every iso-whatnot, etc.
It would really be bet
I wrote:
> ...
> ...
> Lastly, I thought I'd go ahead and add the ability to set
> not just the gradient object's fill-angle, but to allow one to
> set further transforms on the fill.. eg. to skew the fill, and
> what the heck, might as well allow for perspective projections
> as wel
Michael Lauer writes:
> Jose,
>
> all your gradient work is very exciting, however I think
> quite a few people lost track over what we now can do
> with gradients. Would it be too much asked if you could
> tease us with a couple of screenshots laying out the
> new gradient possibilities
I'm about to move out of evas-gradient-land for a while
and thought I'd mention some the last bits on them here, in case
anyone has any comments or suggestions.
I've recently added support for setting a (file,key) on a
grad obj, so that one can load spectra via evas' image loaders
Carsten writes:
> On Fri, 6 Oct 2006 13:31:19 +0200 "Jorge Luis Zapata Muga"
> <[EMAIL PROTECTED]> babbled:
> ...
> ...
>
> > btw a little offtopic, but now that the premul stuff is in,
> > isnt a good time to continue thinking/start coding the
> > > Likely evas will have general obj clipping not too far away,
> > > but 'buffer evases' are also interesting and useful (hence the
> > > ecore sub-canvases).
> >
> > I think it would be indeed really useful to have such objects:
> > I may be wrong but I think this kind of objects is the wa
Ok, I took a bit of time to download and look thru Jorge's
"evas_core" work...
It's interesting that what he's done here is pretty much
what we've been going over, though it may not have seemed that way
to him :)
Jorge:
It doesn't matter what an 'engine' does with
> > Chad writes:
> >
> > > I'm not sure if this is the same problem, but here is a
> > > screenshot I just took that may be realted:
> > > http://www.lunar-linux.org/~v3rt1g0/fuzzy.png
> > >
> > > ...
> > > ...
> >
> > That's pretty bizarre indeed. Anyone else experienced
> > a simil
Daniel writes:
> Not really. Have a look at this:
> http://entropy.homelinux.org/blurry.png
> I'm *almost* certain that last time I created an icon for
> firefox based on the same svg, it scaled up perfectly.
That actually looks about right.. it looks like what you'd
get if you
Chad writes:
> I'm not sure if this is the same problem, but here is a screenshot
> I just took that may be realted:
> http://www.lunar-linux.org/~v3rt1g0/fuzzy.png
>
> On the left is iBar, with the orange BMPx icon. Presumably that
> same icon is also what you see in iBox on the right.
Ok, now that I have a bit more time to reply... :)
> i have a few doubts about objects and engines and how to implement
> what we need. I think the idea of making engines be just blitters
> is a good thing, also convert the objects to module units. But
> (as you noted) we have a problem w
I'll get back your other points a bit later Jorge :)
But let me just quickly reply to the following part:
> call an engine function (this is why it is called "object engine")
> which will send a protocol command. The problem with this is that
> now almost every "canvas api" function (obje
> > Hi all.
> >
> > I can't be sure about this, but I *think* the quality of icons
> > based on svg images has dropped recently. If I make an application
>
> I can't really imagine why they would look much different, vs.
> scaling pngs, now from before. As raster mentions, it uses the same
> sca
> > Hi all.
> >
> > I can't be sure about this, but I *think* the quality of icons
> > based on svg images has dropped recently. If I make an application
> > icon based on a png file, when I put it in the bar and point at it
> > ( with the darkness theme, that zooms icons when you point at the
>
> To be continued :)
>
Well, the prior emails pretty much outline all that I have in
mind here as far as objs/engines re-structuring: Modular units which
when called upon to add an evas obj to an evas canvas would either
use a default 'generic' set of funcs, or load an implement
Wagner writes:
>
>
>
> so, now are my questions :
>
> would it be a good idea to add support for arabic text
> (and hebrew, and complex languages) ?
>
> which functions would need to be modified ?
> (are for example some functions returning string lenghts ?)
>
> how is text i
> Ok, so what are the set of basic engine funcs, and obj
> funcs, that will need to be provided?
>
> To be continued :)
>
Well, let's take a look at 'objs' first. Internally, the
basic evas_obj structure keeps some things that we're interested
in here:
Its 'type'
> > I thought that Jorge (aka. turran) was going to do some
> > work on the evas fb engine, and also ecore_fb, but don't know if
> > he's had a chance to get to that or not.
>
> yeah i do have plans for it, but with the changes on the way evas
> engines will behave, i prefer to not touch it
> > I can use it for hours/days/... and get a different idea,
> > and I can look thru the src code and get yet another viewpoint..
> > But neither will equal that 'first-impression' viewpoint.
>
> the fallacy is that you have first impressions of something
> totally incomplete.
>
> "this house i
David writes:
> > Sardines are quite good with beer or wine.
>
> Don't like beer or wine either.
Hopefully, after seeing how much was done in such a short
time, someone else will step up to the plate.. and offer something
better ;)
jose.
--
Nathan writes:
> I received a bug report from Lutin on #edevelop today that
> indicated that evas would not build on PPC linux with the FB
> engine enabled because PAGE_MASK is not defined.
>
I thought that Jorge (aka. turran) was going to do some
work on the evas fb engine, and
> > > I have some personal criticisms and requests though,
> > > just based on first impressions of a few minutes of use... :)
> >
> > You should use it for more than a few minutes before complaining.
>
> aye.
>
Naye. First impressions are of the utmost importance,
that's why I deli
I hadn't run e17 for a few months, and just recently
updated it and did so.. Many new good things here - imagine
how much could be done if the work done over the last couple
of months could continue! :)
I have some personal criticisms and requests though,
just based on first impr
As I mentioned in an earlier email (which for some reason
I've yet to see show up), the odd behaviour of grads w.r.t. changing
bgs in e17, turned out to be entirely due to an error in the evas
grad code, NOT in edje.. Brian's edje-grads work fine! :)
Attached is an evas patch to take care
I wrote:
> I think this is some subtle grad id problem, or some such, in
> the way edje grads are defined.. or some other part of the code that
> may deal with 'transitions'.
>
and also,
> Since Brian is busy with things, it looks like I may have to
> see if I can so
I wrote:
> I think this is some subtle grad id problem, or some such, in
> the way edje grads are defined.. or some other part of the code that
> may deal with 'transitions'.
Ummm I wonder if it may be that there's absolutely no
support for edje grads in edje_embryo. Th
> > Did this happen before the move to premul?
>
> no - i think it worked.
>
You don't sound too certain.. ;)
It's possible but I'm having doubts that it ever did.
Here's why:
1. It works fine for images.
2. Grad recoloring works just fine in evas.
3. I actually modified ed
Brian writes:
> I'll look at the bg dialog within the next couple of days
> (pretty busy with work atm. unfortunately). And I definitely
> plan on cleaning up the edje grads a bit. Just gotta find some
> time again. :)
Sounds good :) Edje grads should be easier and more
flexib
> > also, line 1329 should now read:
> >
> > evas_object_gradient_color_stop_add(ep->object,
> > sc->r, sc->g, sc->b, 255, sc->d);
> > evas_object_gradient_alpha_stop_add(ep->object, sc->a, sc->d);
>
> hmm - color stop can't add the alpha directly as-is?
Yes,
> > Ummm... How about adding a 'premul' flag to eet images, which
> > would be set/read accordingly...
>
> i could... but i would need to break eet api... and i'm just as
> happy to break format - premul encoding can be more efficient
> compression-wise by nulling out transparent pixels. :)
> Author : raster
> Project : e17
> Module : libs/evas
>
> Dir : e17/libs/evas/src/modules/loaders/eet
>
> Modified Files: evas_image_load_eet.c
>
> Log Message:
>
> fix eet load of premul images - need to check they are not "bad" :)
>
Ummm... How about adding a 'premul' flag
> > Just to let anyone who might be wondering what happenend --
> > I've sent a copy to raster and he's already on it... :)
>
> and the bitch has hit cvs :)
Oh boy.
Man that's remarkable you were able to get so much stuff
fixed up to work with it so quickly.. :)
> Attachements still a no-op. Ummm. will try again another time
> and see if I have better luck then.
>
> jose.
It seems that sf doesn't like non-text attachments, and this
patch is simply too large uncompressed (like 1.4Mb).
Just to let anyone who might be wondering
Attachements still a no-op. Ummm. will try again another time
and see if I have better luck then.
jose.
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll
> I've attached the evas-premul diff (rather largish but...
Attachement didn't seem to go thru. Ummm... Let's try again
and see what happens (it's a 124Kb "evas_premul.tgz" file).
jose.
-
Take Surveys. Earn C
Vincent writes:
> I have a question. The software engines are working in non-premul,
> whereas the xrender ones do. Is there any improvement in the speed,
> wrt the xrender engines ? (I've not installed your patch yet)
Did it go thru? I seem to not have had it forwarded...
Well long overdue, and could use much more testing.. but
I may as well send this for others to check and test if they wish :)
We've mentioned what this 'evas premul' move means before,
so I won't repeat it here, but anyone with any questions please feel
free to ask.
There
Michael writes:
> Welcome to the Bazaar. If you would prefer to work in a Cathedral,
> please note that you will not find one here.
For either method to work though.. cooperation and a certain
set of guidelines are needed. That's why you have "rights" to CVS
commit access.. For
> it can't. it's a window. just like tray icons. windows cant be
> part of a canvas.
I think that given the current design of the systray spec,
what we have here is just that, currently, implementing this may
give ugly stuff for many systray-apps.. But I don't think it means
that the conc
>Jason writes:
> > > Much ado about gradients, but hopefully all this will make
> > > it easier to work with grads in current edje and otherwise.
> >
> > Forgive me for chiming in when I haven't read the full thread
> > nor grokked the context, but does any of your work allow being
> > abl
> > Nevertheless, yes grads can definately benefit from some
> > optimizations :)
> there we go - that's all i want to mention :) they aren't
> "close to optimal" YET :)
Well, patches are welcome you know :)
Do not frett, o speedfreak.. I've just taken care of it.
> > Much ado about gradients, but hopefully all this will make
> > it easier to work with grads in current edje and otherwise.
> >
> > Comments...?
>
> sounds good - one thing i did notice - gradient fills are a lot
> slower than images... :) i noticed when cross-fading wallpapers
> @ 1600
Jason writes:
> > Much ado about gradients, but hopefully all this will make
> > it easier to work with grads in current edje and otherwise.
>
> Forgive me for chiming in when I haven't read the full thread nor
> grokked the context, but does any of your work allow being able
> to set gra
> > Since we're 'breaking' stuff and going over things -- I went
> > ahead and *removed* the current "evas_object_gradient_data_unset"
> > api function.
> >
> > Why..? Well, its functionality can be obtained by setting
> > new data/adata, or by the colors-clear api func (which will clear
> >
Just a note on the evas move-to-premul stuff. Some things
are taking me a bit more time than I had thought, so it looks like
I may not finish with it til the weekend.. we'll see.
Let me give a quick recap of the api funcs that this change
will involve.
There are four util
> > I want to here what you like. I only want to hear it _once_.
> > I _don't_ want to hear you bitch about what someone else likes.
>
> I want a pony.
>
I want a bicycle.
-
Using Tomcat but need to do more? Need to s
Tilman writes:
> Hi,
> this is about the FIXME in evas_engine_xrender.c:493.
>
> If the depth of the surface is 1, we're passing a scaled variant
> of the identity matrix to the picture.
>
> All scaled variants of the identity should be treated the same
> in the render implementation, but ap
Carsten writes:
> >
> > 1. add api to evas itself to provide size "hints" to loaders
> > (load at size XxY at maximum and retain aspect) as well as dpi
> > hints (you will want both eventually).
> > 2. add api to loaders to be able to do this.
> > 3. actually use this api in the svg loader
>
Nathan writes:
> On 9/6/06, Jorge wrote:
> >
> > well i dont totally agree, i mean, i started this discussion
> > with some ideas i would like to have implemented on evas,
> > i guess jose thinks the same. so this thread is to actually
> > THINK and WRITE what are the future goals of evas
> > Anyway... I think it might be best to let the edc format
> > stay as it is (non-premul colors), and have edje do the
> > conversion, not edje_cc. If desired, a later edje can have other
> > types and/or versions of 'design-formats', like edc, and one can
> > do whatever.. There are possibi
This is slightly 'off-topic' for this thread, but let me
just make it clear that when I 'criticize' evas' this or that, and
whatnot.. it's not to criticize Carsten's work on evas - not by any
means.
It's remarkable what he was able to do with this.. to design
it, and put it togethe
Brian writes:
> > To me the main issue is not really a 'technical' one pre se,
> > it's do people really want, and want to help with, such changes?
> >
>
> Right now, I think the response you're going to get from most of
> us is: "Wait until e17 is out the door." Evas may have issues, bu
Jorge writes:
> > I tell you what, let me look things over a bit during the
> > weekend, and if you like you and maybe Jorge can do the same...
> > maybe discuss it with others on the list who have some experience
> > with evas/objects/engines and we can take it up again on Mon
> > o
Rene writes:
> Hi,
>
> most framebuffer drivers (nvidia, radeon, ...) default to 8bps and
> all non-x86 machines such as PPC ones run this per default. However
> Evas (evas_fb_test) crashes on 8bps because no convert function is
> matched and crashes in
>
> evas_fb_outbuf_fb_get_height
Cedric writes:
> > Many engines have some sort of native notion of a 'buffer'
> > that one can get/put data to, which they can composite to a
> > target surface.. eg. xrender has 'pictures', gl has at least
> > 'textures', etc.. and usually this compositing can be done with
> > some
Jorge writes:
>
>
>
> ok! now i understand what you mean on the first place, i totally
> agree with you.
>
> in the current evas in order to make a new engine you have to
> define all the current engine functions or at least inherit the
> software engine (almost all engines do
Jorge writes:
> >So, the gfx parts of the engines (and some that are not
> > directly gfx aspects) are really mostly a bunch of functions that
> > apply to each object type, and some core functions that apply to
> > all object types, and some that apply to display-target aspects.
> > S
Jorge writes:
> 1. reorder the headers:
> every subsystem has its own header, no more one huge header
> (Evas.h, evas_private.h, evas_common.h). as the main idea of this
> is to allow objects, loaders/savers, engines to be able to build
> outside evas, we need a way to export internal API. So
> The d-linear one will have its spectrum grow from the fill
> origin to the bottom-right of the fill region, ie. diagonally with
> increasing right handed normal to the diagonal.
That should read - "ie. increasing *along* the diagonal".
The lines of constant color are the ones norm
Brian writes:
> How does the current implementation of an evas gradient differ
> from "a rect obj textured by a lin grad"? The rel1/rel2 inside
> the gradient block i added are in the part's coordinates
> (or fixed relative "to" the part).
>
> > So, if you want some simple way to get
> All this solves one issue (specifying a 'dynamic' angle
> e.g. corner to corner) but still doesnt' solve the main issue
> I had. Namely: Draw a horizontal linear gradient completely
> filling its bounding rectangle.
The bounding rect of an (unrotated) gradient object is
the gradient obj
> Once objs can have angles, and we add the notion of path
> objs, like rects, being filled and/or stroked with a texture obj
> (an image or grad obj), then you would have the ability to 'rotate
> after the fill' as you want - but in the same vein as in the vgx
> specs, namely you are fillin
> B) origin/size filling is largely useless for linear grads
> (since its applied before the angle)
I should add that it's absolutely necessary for the
resizing to be done before the rotation, or the whole thing
becomes an inconsistent mess.
The pdf spec for example makes this ve
Brian writes:
> Since this only makes sense for linear grads, i'll probably
> just add:
>
> gradient.rel1.relative
> gradient.rel1.offset
> gradient.rel2.relative
> gradient.rel2.offset
>
> these will only be used by linear grads, overriding fill.angle,
> fill.position.* and fill.size.*
> I realized the inconcistancy when I started implementing this
> (still haven't used gradient types other than linear and radial
> yet -- haven't felt like trawling evas' code for the params,
> hint hint ;)
>
Ah... That's a deliberate omission - the lack of detailed
documentation o
Brian writes:
> A few weeks back, I added gradient support to edje. However,
> I think I need to rework how thigns are done slightly. Here's
> the issue:
>
> Evas applies the fill of a grad BEFORE the rotation due to the
> angle. So, if you want a horizontal grad from left to right (angl
> beware. this is relatively inefficient for icons. the resulting
> evas images are generally big (1000x1000 or bigger). i need to:
>
Ha! They're hard to miss that way :)
Rendering them at any given pixel size is fairly easy:
if their default size is w0xh0 say, and you want them
David:
I've attached a librsvg based svg loader for evas in case
you might find it useful.. it uses a scale of 90 dpi for rendering,
and needs librsvg >= 2.13.
If you want to give this a try, you will have to add it to
evas... then test it, and possibly debug it.. :( I've no
> > > > Not from me, sorry.. :( Feel free to use it or let it go
> > > > as you wish.
> > >
> > > who wants to have a go at this? :)
> > >
> >
> > You once asked me to take evas off your plate, and I told
> > you that I couldn't, and shouldn't, do that.
> > There are many things
> > Not from me, sorry.. :( Feel free to use it or let it go
> > as you wish.
>
> who wants to have a go at this? :)
>
You once asked me to take evas off your plate, and I told
you that I couldn't, and shouldn't, do that.
There are many things about 'maintaining' such a pro
> > This 'one-size-fits-all' approach has its obvious drawbacks..
> > and benefits (eg. one could have runtime loadable types without
> > needing any included files whatever).
>
> i think - if we want to add this, we need to add an api call that
> accepts 3 params for this - if you can do tha
> > > In essence, I know absolutely nothing about using
> > > glib, gdk, etc...
> >
> > the header files directory can be found with pkg-config. Then,
> > you usually have to include glib.h, or gtk/gtk.h, or gdk/gdk.h,
> > etc...
>
> thanks vince :)
Yes, thanks.. how strange to have
Just to get back to the desired evas xpm and svg image
loaders:
I had a chance to test the xpm loader and it seems to
work fine (it's actually difficult to find xpm files these days).
It can do with some cleaning up and some refining but it seems ok
for use as is.
I've al
> > Well, the xpm loader is ready.. I see a few other imlib2
> > loaders that may be desirable (eg. an xcf one), if anyone would
> > like to have any others ported now while I'm at it, do speak up
> > before I move on and start digging into librsvg.
>
> Just a couple quick notes on the port
> > Well, the xpm loader is ready.. I see a few other imlib2
>
> Cool, thanks. I'm looking forward to seeing that committed.
Ok, in case you want to try the xpm loader, I'm attaching
a tgz file with the mininmum stuff it requires :)
The loader itself needs some more cleaning up..
Blake writes:
> > As far as the svg loading: We've already mentioned using
> > librsvg for that - I can give it a try and see how well it can
> > be made to work if no one else wants to do so..
>
> I don't think anyone would be happy to see Evas depending on
> GTK/GDK etc. Like Raste
David writes:
> The user is the logged in user that will be seeing the icons.
> There is a default size of 48x48 if the user doesn't use some
> method of selecting other sizes. There is an fdo specified
> algorithm for searching amongst any installed icon sets for an
> icon that closely
David writes:
> In the context of this thread, the freedesktop.org specs say that
> the user specifies the size in pixels of icons that they want, and
> for svg's, that means we need to render to that particular size.
> There is a default icon size of 48x48 if the user didn't specify
> a
Carsten writes:
> XPM is not hard - loader is in imlbi2 - can be snarfed in.
> svg - well - a bigger issue - but i think we can avoid it for
> now and just display "default" icons in place. as long the the
> "icon finder" routine will return null when no icon can be
> found given the para
> > If at a later point in time evas does get loadable
> > obj types, one would only need to deprecate the use of the
> > 'type_params' string to deal with type-specific data, and
> > instead use whatever type-specific funcs would be available.
>
> I'll second the desire for loadable object t
Cedric writes:
> Hi,
>
> I started a SDL engine for evas and would like some feedback.
> First it's working and you will see something with evas_sdl_test.
> But I have already a few questions.
>
>
>
Well, I don't know anything about SDL, or how useful that
might be,
> > This type, unlike the others, does not use a described
> > geometry, but instead uses an image to specify that.
> > The type has as its params a string of the form:
> >
> > "file:key:mode"
> >
> > Each of file, key, and mode must be present.
>
> personally i would have made this
> > > actually - cairo is unlikely to become a main engine - just
> > > because it's extra work with no gain. we use what cairo uses
> > > directly ourselves already. this gives us better control and
> > > better performance. :)
> >
> > One never knows.. Always keep an open mind! :)
>
> > The cairo dependency is fine since hopefully it'll become
> > a 'main' evas engine.. But it's unfortunate that librsvg has to go
> > thru glib and gdk.. ideally it would keep to a min of xml related
> > libs say, and draw to a cairo surface say.
>
> actually - cairo is unlikely to become
> > > Loading 'SVG icons', at this point in time, really just
> > > means rendering some static SVG doc at some scale and then
> > > using that rendered image.. There are libs that can do that,
> > > the most commonly used by some seems to be 'librsvg', which
> > > latest version seems to use
David writes:
> According to the fdo specs, the user is allowed to select an
> icon size and theme. The spec contains methods of looking
> through the search paths to determine what icon themes and
> sizes are available. There is a fallback size and theme that
> every system must supply
> > If anyone could help out here with a better, fast enough,
> > format-spec-and-decoding-implementation, that would be great :)
> > [ The implementation of this is done in the function
> > "shaped_setup_geom" of the evas_gradient_shaped.c file ]
>
> I would consider using \0 for a separat
> > eg. "/path_to/image.png:NULL:color"
>
> Is there a reason you chose "NULL" instead of just leaving the
> field blank? (filename.ext::mode)
> Also, ':' is a valid character for a filename, so hopefully
> there's a way to escape it? ("/path/to/foo\:bar.png:NULL:color)
>
Unfortu
Attached is a tgz file containing a patch for a new evas
gradient type named "shaped".
This type, unlike the others, does not use a described
geometry, but instead uses an image to specify that.
The type has as its params a string of the form:
"file:key:mode"
Each of file
>
>
>
> >
> > What do you mean by an "object engine"?
> >
>
> Its the abstraction needed to make evoak work, its a special type
> of engine. For example all the evas_object_* are redirected to the
> engine function so evoak (the engine) can send the request to the
> server.
>
> >
> >Just to mildly change the subject here: Did you ever
> > get that evas 'canvas' object, or subcanvas whatever, worked out?
>
> no, not at all. i just emulate it using a smart object. don't know
> if its useull beside my use case.
Oh well.. :( Maybe it can be done a bit l
> Hi all,
> I have several ideas/issues with the framebuffer and evas
> (also ecore_fb):
>
>
>
>
>
> I send this to know your opinions before i do any changes to the
> current code.
> best regards,
>
> turran
>
So, you'd like to change the semantics of the e
> I committed a large chunk of the code for edje grads last night.
> I added angle and spread to the fill block, and reused the rest
> of fill (origin, size) for the grad fill. Angle will be interpolated
> during transitions, as will fill. The other params (spectrum, and
> spread for now) flip at
> I would make the geometric 'type' its own block tag though
> > (you could also call it 'geometry' instead of 'type' if you like),
> > of the form say,
> >
> > type {
> >name: "type_name";
> >params: "whatever";
> > }
> >
>
> to keep things from getting too deep, how abouting
>
> par
> >
> > First, I would put the 'angle' and 'spread' properties
> > under the general 'fill' tag. This is because that's really
> > where they belong logically (describes various aspects of the
> > way the filling of the object region is done), and also because
> > image objects are going to g
> > > so you can define gradients for a bg - but store the saved
> > > config in a .edj file. use an imag with a pre-rendered
> > > alpha->white gradient (horz, vert, radial) then use a bg rect
> > > for one color and set the color of the gradient image object
> > > to determine the 2nd color for
As part of a recent cvs commit of various e "TODO" stuff,
Carsten writes:
> * bg needs a gradient dialog that can take a set of pre-drawn
> png's and edc recipies and use colored rects and overlayed
> png's recolored with color options to create vertical,
> horizontal, radial etc. g
Ok, lets see if we can decide on this.. so that actual work
can be done :)
I'll outline below my current proposal for moving evas over
to alpha premul color space.
But before doing so, let me note that we don't have to do
this in order to have an xrender engine which is c
Jose writes:
> >
> > correct. non-premul to premul is destructive. VISUALLY it will look
> > the same when composited, BUT this should be an understanding -
> > correct.
> >
>
> Yes, that's right. It destroys the superflous information
> that may be contained in the overdetermine
> > With the added stipulation that the data returned may not be
> > exactly the data given (due to colorspaces not mapping 1-1 on
> > each other). Unless you plan on keeping the untouched data around
> > somewhere (which would double the memory usage).
>
> correct. non-premul to premul is destru
201 - 300 of 357 matches
Mail list logo
