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 ... > 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 ;). Thanks! hendrik ------------------------------------------------------------------------- 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
