Re: [E-devel] [Evas] possible bug in gradient
>> So, if anyone has any comments, suggestions, issues.. *anything* with >> evas gradients -- now would be a good time to pipe in. :) >> > > I'd _love_ using gradients, in fact I would use them much more often, _if_ > not > everytime I start using them, it all feels like I'm operating a powerful > machine that has 100s of controls and I don't understand anything. > > Perhaps this is an inherent problem from the gradient complexity, but I'd > appreciate if we had some documentary material that outlines how to achieve > which kind of results, which gradient type to use for what, how many stops > for what effect etc. etc. > Ok, let me try and give you a fairly simplified description of what gradients are basically about, and how evas tries to deal with this.. for better or worse. There are really two independent aspects to gradients: 1. A 1-dim image of possibly variable length. 2. A means of mapping this image onto a planar region to create a 2-dim image, and this is what's often wrapped under the term of the 'type' of gradient, as well as other things such as the 'repeat-mode' and other stuff. For (1), there are multitudes of ways one can use to define such a 1-dim image, and everyone has their own idea of what a simple, or natural, or powerful, or whatever favorite way. Often, this is given in a 'procedural' way and involves specifying some set of colors strung out along some abstract line element. One then interpolates 'in-between' the given colors to obtain the full 1-dim image of colors. One common method for such a description is eg. what's specified in the svg spec, namely one gives a sequence of colors and positions on the [0,1] interval. Imlib2 allows one to specify a sequence of colors and some abstract 'distance' to the next color. Evas has something similar but the distance is more like a 'weight' for that color. The Gimp allows one to define some sequence of colors together with the position of the 'half-way' color (or some such, I can't recall anymore), and allows for various kinds of interpolation in-between (linear and some others). There are others as well. So you see, there are any number of ways to 'specify' what the 1-dim image is to be, abstractly or not, and in evas I went ahead and just allowed you to give a 1-dim image as well, in case you don't want to bother with some procedural representations. In general, we may ask: What should be the kinds of such descriptive means that evas should support for defining the 1-dim image (or 'spectrum' as I've sometimes called it) that one needs for gradients? Now, for (2), there are again any number of means by which one can map a 1-dim image onto a planar region, but a common one used is to give a function float f(float x, float y) which is used roughly as follows: "for input (x,y) let r = f(x,y), and somehow pick a color on the 1-dim image that corresponds to this r". For example, a "linear gradient" corresponds to any number of linear functions of x, y, eg. anything of the form f(x,y) = a*x + b*y; will define a 'linear gradient'. Similarly, a "radial gradient" can be defined by the function f(x,y) = sqrt(x*x + y*y); or similar quadratic functions of x,y. An "angular gradient" can be defined by "atan2(y,x)"; a "rectangular gradient" by the func f(x,y) = max(|x|,|y|); an "8-pointed star gradient" can be defined by f(x,y) = (1 + 1/(4-2*sqrt(2)))/2 * min((1 / sqrt(2))*(|x|+|y|), max (|x|,|y|)); a "sinusoidal gradient" by f(x,y) = y - sin(a*x); and the list is of course endless. The thing about many of these functions is that the values r = f(x,y) can vary arbitrarily, and one wants the gradient to be somehow 'fitted' to a given planar region it can minimally fill (thus effectively determining the range of the 1-dim image), hence one needs to map those values of 'r' to be within the range of the 1-dim image. This is what gives rise to the various repeat (or extend, or spread) modes.. things like repeat/reflect/pad/... Given this infinite flexibility as to gradient "types" and the various kinds of 'geometries' that those implicitly define, people often tend to pick one or two common ones and define separate apis for the particulars of those geometries. For example, for linear gradients people often expose something like "the linear gradient from point p0 to point p1", or "the radial gradient centered at point c and of radius r", and similar such specialized things - one set of api funcs for each gradient 'type'. In general, we may again ask: What should be the descriptive methods that evas should support for defining the 'types' of geometric mappings that one wants for gradients? What's in evas right now (and also part of the latest proposal on having another method of defining gradient spectra) is one attempt to answer these two questions subject to certain constraints: a) Retain some flexibility - eg. one can define new gradient types eas
Re: [E-devel] [RFC] Async preload of image data
On Mon, Jun 23, 2008 at 6:14 PM, The Rasterman Carsten Haitzler <[EMAIL PROTECTED]> wrote: > On Wed, 18 Jun 2008 18:53:06 +0200 "Cedric BAIL" <[EMAIL PROTECTED]> babbled: >> Hi, >> >> Here is a patch that add support for background preloading of a data >> image. You can now, if you know what you do, ask evas to load the data >> of an image in memory before it is displayed (look at the sample code >> for expedite). >> >> The code is quite simple, we have now a work queue where we add all >> the Image_Entry we need to preload. They are processed one after the >> other in another thread. When it's done, it notify evas main thread >> with evas async API and work on the next Image_Entry. >> >> This means that we now require that engine surface creation and >> loader should be thread safe. It's currently the case for all the >> engine I know something about, so this should not break anything. >> Anyway this code is optionnal and could be completely unactivated in a >> per engine basis or globally. >> >> As always have fun reviewing this patch. > > hmmm - i like the idea - yes. missing cache surface alloc mutex :( that should > not be hard to add - a little bit of extra code. also missing Evas.h prototype > for exporting the preload call. looks like most engines have the calls > supported. the problem is what to do out fd'with the locks on alloc. as such > it > is unlikely to cause problems as it stands in the patch - but may if the alloc > happens while deleting/freeing an image. the images themselves all need locks > now for anything accessing them. I don't think so as the path that will generate the async load as only one way to interfer with the other load path and this one is protected. Their was just one possibility that the engine wasn't thread safe during the surface allocation and that could be a problem. So now I attached a patch with a mutex around the surface allocation (it also as some more autofoo patch). This is just an updated patch, I don't know if I want to apply it as many people expressed interresting opinion in this thread and I need to make my own opinion on the issues/ideas they raised. I will be back. -- Cedric BAIL diff --git a/configure.in b/configure.in index 78c67be..b78bbdc 100644 --- a/configure.in +++ b/configure.in @@ -1135,16 +1135,24 @@ pthread_cflags="" pthread_libs="" build_pthreads="no" has_pthreads="no" +need_pthreads="no" +# basic pthread support +AC_CHECK_HEADER(pthread.h, + [ + has_pthreads="yes" + ], + [ + has_pthreads="no" + ] +) + # sched_getaffinity pthread_attr_setaffinity_np AC_CHECK_HEADERS(pthread.h sched.h, [ AC_CHECK_LIB(pthread, pthread_attr_setaffinity_np, [ AC_CHECK_LIB(pthread, pthread_barrier_wait, - [ - build_pthreads="yes" - has_pthreads="yes" - ], + [ build_pthreads="yes" ], [ build_pthreads="no" ] ) ], @@ -1165,8 +1173,7 @@ AC_ARG_ENABLE(pthreads, AC_MSG_RESULT(yes) AC_DEFINE(BUILD_PTHREAD, 1, [Build Threaded Rendering]) build_pthreads="yes" - pthread_cflags="" - pthread_libs="-lpthread" + need_pthreads="yes" else if "x$use_strict" = "xyes"; then AC_MSG_ERROR(pthreads headers or functions not found (strict dependencies checking)) @@ -1183,8 +1190,7 @@ AC_ARG_ENABLE(pthreads, AC_MSG_RESULT($build_pthreads) if test "x$build_pthreads" = "xyes" ; then AC_DEFINE(BUILD_PTHREAD, 1, [Build Threaded Rendering]) - pthread_cflags="" - pthread_libs="-lpthread" + need_pthreads="yes" fi ] ) @@ -1204,12 +1210,45 @@ if test \( "x$build_async_events" = "xyes" -o "x$build_async_events" = "xauto" \ AC_MSG_RESULT(yes) AC_DEFINE(BUILD_ASYNC_EVENTS, 1, [Build async events support]) build_async_events="yes" + need_pthreads="yes" else AC_MSG_RESULT(no) build_async_events="no" fi ### +## Async image preload +build_async_preload="auto" +AC_MSG_CHECKING(whether to build Async Image Preload support) +AC_ARG_ENABLE(async-preload, + AC_HELP_STRING([--enable-async-preload], [enable async image preloading support]), + [ build_async_preload=$enableval ] +) +AC_MSG_RESULT($build_async_preload) + +AC_MSG_CHECKING(whether we can build Async Image Preload support) +if test \( "x$build_async_preload" = "xyes" -o "x$build_async_preload" = "xauto" \) -a "x$build_async_events" = "xyes"; then + AC_MSG_RESULT(yes) + AC_DEFINE(BUILD_ASYNC_PRELOAD, 1, [Build async image preload support]) + build_async_preload="yes" + need_pthreads="yes" +else + AC_MSG_RESULT(no) + build_async_preload="no" +fi + +### +## Link with pthread if needed +AC_MSG_CHECKING(whether we should link with pthread) +if test "x$need_pthreads" = "xyes"; then + AC_MSG_RESULT(yes) + pthread_cflags="" + pthread_libs="-lpthread" +else + AC_MSG_RESULT(no) +fi + +
Re: [E-devel] [RFC] EET crypto and signature support.
On Tue, Jun 24, 2008 at 7:27 AM, The Rasterman Carsten Haitzler <[EMAIL PROTECTED]> wrote: > On Tue, 24 Jun 2008 00:48:04 -0400 Simon Horman <[EMAIL PROTECTED]> babbled: > >> I'm not exactly sure what you are planing to push into and pull out of >> this API, but it might be more sensible to provide the key on open. And >> then use a scheme like CBC to encode a stream of data until it is done. >> Then close. Or in other words; start(); add_data()...; finish(); > > as eet files can store multiple (independent) data segments - addressed by key > strings (like a tar.gz with multilple files in it) it makes the most sense for > the key to be provided along with reading/writing a specific data segment - > no? > >> Having a pool of registered keys might make sense if it is envisaged >> that more than one might be used at a time - though not on the same >> set of data. > makes sense if we consider the whole file encrypted, but as such why limit it > to a set of keys you have to set up in advance (other than performance)? :) The idea of setting up the key in advance give us the possibility to set them outside of the direct user of the eet file. We can cypher an edje collection and without any modification to edje library use it. Same goes with any user of eet, no need to change it. Only the apps that want to use this feature will need a change (and of course they will need it as they need a way to provide the key). -- Cedric BAIL - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Nightly build log for E17 on 2008-06-26 07:09:43 -0700
Build log for Enlightenment DR 0.17 on 2008-06-26 07:09:43 -0700 Build logs are available at http://download.enlightenment.org/tests/logs Packages that failed to build: edvi http://download.enlightenment.org/tests/logs/edvi.log enna http://download.enlightenment.org/tests/logs/enna.log epdf http://download.enlightenment.org/tests/logs/epdf.log evolve http://download.enlightenment.org/tests/logs/evolve.log express http://download.enlightenment.org/tests/logs/express.log Packages with no supported build system: entice, esmart_rsvg, exorcist, python-efl, Packages skipped: camE, ecore_dbus, engage, enotes, enscribe, epbb, eplay, erss, etk_server, etox, e_utils, Evas_Perl, evoak, gfx_routines, lvs-gui, med, nexus, notgame, ruby-efl, webcam, Packages that build OK: alarm, bling, calendar, cpu, deskshow, echo, eclair, ecore_li, ecore, edata, edb, e_dbus, edje_editor, edje, edje_viewer, eet, eflame, eflpp, efm_nav, efm_path, efreet, elapse, elation, elicit, elitaire, e, embrace, embryo, emotion, emphasis, empower, emprint, emu, enesim, engrave, engycad, enhance, enity, enterminus, enthrall, entrance_edit_gui, entrance, entropy, envision, epeg, ephoto, e_phys, epsilon, epx, equate, esmart, estickies, etk_extra, etk, etk-perl, evas, evfs, ewl, examine, execwatch, exhibit, exml, expedite, exquisite, extrackt, feh, flame, forecasts, gevas2, iconbar, iiirk, imlib2_loaders, imlib2, Imlib2_Perl, imlib2_tools, language, mail, mem, mixer, moon, mpdule, net, news, notification, penguins, pesh, photo, rage, rain, screenshot, scrot, slideshow, snow, taskbar, tclock, uptime, weather, winselector, wlan, Debian GNU/Linux 4.0 \n \l Linux enlightenment2 2.6.18-4-686 #1 SMP Wed May 9 23:03:12 UTC 2007 i686 GNU/Linux See http://download.enlightenment.org/tests/ for details. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [RFC] EET crypto and signature support.
On Tue, Jun 24, 2008 at 03:27:30PM +1000, Carsten Haitzler wrote: > On Tue, 24 Jun 2008 00:48:04 -0400 Simon Horman <[EMAIL PROTECTED]> babbled: > > > I'm not exactly sure what you are planing to push into and pull out of > > this API, but it might be more sensible to provide the key on open. And > > then use a scheme like CBC to encode a stream of data until it is done. > > Then close. Or in other words; start(); add_data()...; finish(); > > as eet files can store multiple (independent) data segments - addressed by key > strings (like a tar.gz with multilple files in it) it makes the most sense for > the key to be provided along with reading/writing a specific data segment - > no? If you just want to encrypt/unencrypt things at the granularity of what is accessed using read/write, then yes, what you suggested makes good sense. The API that I was getting at would work well in situations where an encrypted chunk of data would be built up using muiltiple writes(), presumably because its either very large or isn't all available in one hit for some reason. That doesn't seem to be the case here. > > > Having a pool of registered keys might make sense if it is envisaged > > that more than one might be used at a time - though not on the same > > set of data. > > makes sense if we consider the whole file encrypted, but as such why limit it > to a set of keys you have to set up in advance (other than performance)? :) Cedric made a subsequent post on this. > > With regards do zeroing RAM, that is a good idea. But its really all a > > bit moot if the memory is swappable. > > sure - though as such it would massively reduce the likelihood of > inadvertent passkey trails in core dumps etc. swap we can't do > anything about - but if you copy the key, use it and derivative data > really fast them nuke everything "chances" of it being found later by > mistake are lower. it's definitely not a solution, but a risk > mitigation at any rate. if you have access to the memory space of a > process to be able to do this it's normally game over anyway, but > there is not much we can do there beyond mlock()... and then we're in > root-only land. Agreed. Though it may be worth using mlock() if the euid happens to be 0. -- Horms - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [RFC] EET crypto and signature support.
On Thu, Jun 26, 2008 at 02:22:00PM +0200, Cedric BAIL wrote: > On Tue, Jun 24, 2008 at 7:27 AM, The Rasterman Carsten Haitzler > <[EMAIL PROTECTED]> wrote: > > On Tue, 24 Jun 2008 00:48:04 -0400 Simon Horman <[EMAIL PROTECTED]> babbled: > > > >> I'm not exactly sure what you are planing to push into and pull out of > >> this API, but it might be more sensible to provide the key on open. And > >> then use a scheme like CBC to encode a stream of data until it is done. > >> Then close. Or in other words; start(); add_data()...; finish(); > > > > as eet files can store multiple (independent) data segments - addressed by > > key > > strings (like a tar.gz with multilple files in it) it makes the most sense > > for > > the key to be provided along with reading/writing a specific data segment - > > no? > > > >> Having a pool of registered keys might make sense if it is envisaged > >> that more than one might be used at a time - though not on the same > >> set of data. > > > makes sense if we consider the whole file encrypted, but as such why limit > > it > > to a set of keys you have to set up in advance (other than performance)? :) > > The idea of setting up the key in advance give us the possibility to > set them outside of the direct user of the eet file. We can cypher an > edje collection and without any modification to edje library use it. > Same goes with any user of eet, no need to change it. Only the apps > that want to use this feature will need a change (and of course they > will need it as they need a way to provide the key). Another issue may be if keys need to be unlocked using a passphrase or other wise initialised in an interactive or expensive way. If that were the case it would make sense to initialise each key once per session rather than each time a read() or write() was performed. Cedric, with regards to your initial question of using an existing scheme or creating a new one. I would suggest the former as getting such scheme right can be tricky, so its usually better to use established methods. -- Horms - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
