summaryrefslogtreecommitdiff
path: root/src/lib/evas/common/evas_image.h (follow)
AgeCommit message (Collapse)Author
2020-12-15evas: Rename EAPI macro to EVAS_API in Evas libraryFelipe Magno de Almeida
Summary: Patch from a series of patches to rename EAPI symbols to specific library DSOs. = The Rationale = This patch is from a series of patches to rename EAPI symbols to specific library DSOs. EAPI was designed to be able to pass `__attribute__ ((visibility ("default")))` for symbols with GCC, which would mean that even if -fvisibility=hidden was used when compiling the library, the needed symbols would get exported. MSVC __almost__ works like GCC (or mingw) in which you can declare everything as export and it will just work (slower, but it will work). But there's a caveat: global variables will not work the same way for MSVC, but works for mingw and GCC. For global variables (as opposed to functions), MSVC requires correct DSO visibility for MSVC: instead of declaring a symbol as export for everything, you need to declare it as import when importing from another DSO and export when defining it locally. With current EAPI definitions, we get the following example working in mingw and MSVC (observe it doesn't define any global variables as exported symbols). Example 1: dll1: ``` EAPI void foo(void); EAPI void bar() { foo(); } ``` dll2: ``` EAPI void foo() { printf ("foo\n"); } ``` This works fine with API defined as __declspec(dllexport) in both cases and for gcc defining as `__atttribute__((visibility("default")))`. However, the following: Example 2: dll1: ``` EAPI extern int foo; EAPI void foobar(void); EAPI void bar() { foo = 5; foobar(); } ``` dll2: ``` EAPI int foo = 0; EAPI void foobar() { printf ("foo %d\n", foo); } ``` This will work on mingw but will not work for MSVC. And that's why LIBAPI is the only solution that works for MSVC. Co-authored-by: João Paulo Taylor Ienczak Zanette <jpaulotiz@gmail.com> Co-authored-by: Lucas Cavalcante de Sousa <lucks.sousa@gmail.com> Co-authored-by: Ricardo Campos <ricardo.campos@expertise.dev> Reviewers: vtorri, woohyun, jptiz, lucas Reviewed By: vtorri, lucas Subscribers: cedric, #reviewers, #committers Tags: #efl Differential Revision: https://phab.enlightenment.org/D12214
2020-02-14Revert "evas: remove unused function evas_common_load_image_from_file."Mike Blumenkrantz
Summary: This reverts commit 7672d1050ea9e1050c27ce2eda68718ea054b638. Depends on D11335 Reviewers: raster Subscribers: cedric, #reviewers, #committers Tags: #efl Differential Revision: https://phab.enlightenment.org/D11336
2018-08-30evas-common: Remove cserve2 supportChris Michael
ref T7226 Depends on D6934
2017-10-05evas: remove unused function evas_common_load_image_from_file.Cedric BAIL
2016-09-06evas: Change internal function image_data_directJean-Philippe Andre
2016-03-28Evas: Add SW engine map/unmap functionsJean-Philippe Andre
Also, fix some of the code using them.
2016-03-15Evas Image: Implement Gfx.Buffer get/set/copy_set APIsJean-Philippe Andre
Those APIs should provide a cleaner interface than the old data_set/data_get APIs, by making sure the operations are atomic (ie. no need to call size_set, cspace_set and then data_set). padding/duplicated borders are not supported. TODO: Implement legacy API on top of the new API, instead of this quick patch
2015-07-12evas - unload/scalecache self-feeding loop unload/reload fixCarsten Haitzler (Rasterman)
i was runing perf top and noticed that evas_image_load_file_data_eet(0 was being called. in fact - it was #1 on the list of functions being called. why? it didn't make sense. i found out. just a blinking cursor in terminology was causing the background to be unloaded and re-loaded. the new "actually unload" changes for 1.15 made this happen and thus we kept sucking in new data all the time even if the scalecache already had the data - and that was the problem. so now calcecache prepare tells you if you don't have cached data and if you likely then have to ensure the data is loaded. this cuts down quite a bit of work. while i'm at it... we definitely need to clean house on the internals of evas. a decade+ of features, mess, optimizations needs to be fixed. i mean really house-cleaned. rewritten clenl;y re-using existing code where appropriate.
2015-07-07evas - image core - fix unloading of images to work againCarsten Haitzler (Rasterman)
i think this has been disabled for a while. image unloading is broken - esp with gl enigne as due to async move it was effectively disabled. this re-enables it. unloading is deferred with a managed list of things needing unloading and then when any async sw renders are not busy any more - do the unload then in the mainloop of all pending/flagged images to unload @fix
2014-06-13Evas: Add encoding parameter to the saversJean-Philippe Andre
ecore_evas_convert: Add -e/--encoding option This uses directly the encoding parameter. For now, used only by the TGV saver, but there is no other way to specify between ETC1 and ETC2. And we don't have a mixed ETC1+2 mode (yet). @feature
2013-05-08evas: add infrastructure to open from Eina_File.Cedric Bail
2013-05-08evas: Make Evas_Loader API public.Cedric Bail
2013-01-16evas/async_render: fix scalecache integrationUlisses Furquim
Note: scalecache is really crazy stuff, we should rewrite it or get rid of it. SVN revision: 82912
2013-01-16evas/async_render: use image scalecacheUlisses Furquim
SVN revision: 82890
2012-11-04merge: and now EvasVincent Torri
I've tested make -j 3 install and it works nicely I've tested expedite with software and opengl xlib, and it works. Not tested other engines, so please report any problems (engines or other) on the ML. TODO: examples and tests, I'll add them later ISSUE: Eina_Unicode size check. It indirectly depends on eina_config.h, which is created at the end of the configure script. So its size is always 0. I don't know how that size is used, so I can't do a lot, for now. SVN revision: 78895