Carsten Haitzler (The Rasterman) wrote:
> On Sun, 21 Sep 2008 17:58:52 +0200 "Hendrik Siedelmann"
> <[EMAIL PROTECTED]> babbled:
>
>
>> 2008/9/20 The Rasterman Carsten Haitzler <[EMAIL PROTECTED]>:
>>
>>> ok basically scrolling. not likely to happen. the problem with the test
>>> code is
>>> - it may have the ability to detect "motion vectors" but it also adds
>>> constant overhead. in the end i am doubtful if it would be that useful in
>>> the long-run. right now as we are basically awaiting a lot of re-do in the
>>> engine-space i dont think i'll be touching this as it would directly fiddle
>>> with the engines and their api. really you suffer from the hardware
>>> platform being 1. very slow with the cpu and 2. with a really slow video
>>> bus. gtk apps only are smooth as scrolling is one of the few things
>>> accelerated and thus they use it. the problem is scrolling in a more
>>> general setup with alpha blending etc. ends up being a redraw - and evas
>>> just always does it this way.
>>>
>> Okay that's a no-go for evas in general :(. But as it stands I am
>> programming for the FR. In fact I found the cpu pretty fast (if not
>> blocked by glamo...). So is there a way to upload pixmaps using evas
>> and ecore? I found ecore_x_pixmap_paste but don't know how to get
>> pixmap from evas, or the graphic context ...
>>
>
> ok. it's possible - you're going to have to manually set up evas , a
> idle_enterer to render etc, (or just render whenever you want). you can render
> to a pixmap. ecore_evas oes this "for you" to handle backing pixmaps etc. so
> you can look there for setup, but just set the target drawable as the pixmap
> and evas will happily render to it. :)
>
>
>>> as for epsilon, it does the "fdo standard", and this requires thumbnails to
>>> be png. yes - writing jpeg thumbnasils is faster, uses less space etc. -
>>> it'd be possible to extend espilon to write .eet thumbs using jpeg lossy
>>> encoding (and thus also have an alpha channel available), but then you'd
>>> have thumbnails "not according to the spec". so it'd be possible to do
>>> this, just the png writing code in epsilon needs a little abstraction -
>>> patches accepted! (sorry - this isn't on my focus right now so will have to
>>> just wait for patches):)
>>>
>> No problem, I have some patches which convert epsilon to simple jpeg
>> writing with fdo naming conventions. Making it a runtime option like
>> the size looks simple. But it's not finished, I don't quite get
>> epsilon_thumbd, it completely breaks.
>>
>>
>>> as for evas loaders, documentation - no, except samples - many of them. they
>>> are very simple though. look at the ppm ones (pmaps). they are simple file
>>> formats. doesnt include a saver there. but.. for the jpeg loader using
>>> embedded thumbnails - no support (would need to know about all the exif
>>> tags and extension data), BUT you can use the more generic load options
>>> which can play a trick of pre-scaling on load ANY jpeg image (embedded
>>> thumbnail or not) and it basically just loads and decodes only part of the
>>> jpeg data. you can get up to a 1/8th scale "for free" (in fact it loads
>>> much faster than a full load). e17's e_thumb uses this
>>> (evas_object_image_load_size_set for example). it requests the image to be
>>> loaded at that size (scaling done on load). :)
>>>
>> Jep I know of that. And using it (evas is simply great). Still slow
>> (actually fast enough, but but faster thumbnails never hurt). I'll
>> look at the samples, used libexif before to extract thumbnails, and
>> also dcraw and I'd love to do a extract-loader with libexif and dcraw,
>> which would itself then utilize the jpeg and ppm loaders. Well in some
>> distant future ;).
>>
>
> wouldn't we all love more features! :) only so many hours a day... :)
>
Yeah. And btw, remember to warn people when using the image load
options, that like the jpg lib itself, though you can set any scaling
fraction
you want, you might not always get the output size intended.. or at least
that that might not be implemented anytime soon. :)
____________________________________________________________
Click here for free search of religious schools located near you.
http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3oJxrJ7dnvwzIn5l7IED9uLo0rdOnWc08zKuiUZwJLeRbSqQ/
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
