This:
1. opens a file
2. maps its data and vaguely verifies it
3. writes data to it
4. writes data to it with a GRY8 map
5. verifies that the final image has all the proper pixels
1. unsigned char* as a return type was not even compatible
with the default colorspace (ARGB: 32 bits).
2. Change all unsigned to int for... uh... simplicity
unsigned is more correct than int for things like width,
size or stride, but in fact having both ints (x,y) and unsigned
ints makes the code more complex.
This is a matter of personal taste.
Those and many more will be required for proper map/unmap support.
There will be problems with planar formats:
YUV, RGB565_A5P, ETC1_ALPHA
The quick solution to this problem is to not support region
conversions, only full-image (so we can assume the location of
the various planes in memory).
This will be properly implemented by the subclasses. In particular,
map/unmap will be used where it makes sense, and data_get/set will
be limited to Efl.Canvas.Image and Surface.
A small hack to the toolchain allows us to generate enums with eolian
for use by Eet and Emile (internal or otherwise non-eo libraries).
Thanks to how BUILT_SOURCES works, the eo.h files required by Emile
will be generated before they are used.
This adds a partial dependency on eo for eet and emile:
- package dependency
- include dependency
There is no library link dependency.
An otherwise good looking macro triggers a warning with clang,
because of self comparison of constants (always true or always
false). Let's just silence the warning in this specific spot
with a pragma.
Summary:
Support hexadecimal color code in EDC.
Four types of color code are acceptable.
All values below mean 'Red'. (255 0 0 255)
color: "#F00";
color: "#F00F";
color: "#FF0000";
color: "#FF0000FF";
Color code tables are usually provided with hexadecimal numbers.
Supporting hexadecimal color code will allow developers to skip
manual conversion hex to decimal.
Test Plan: Test case will provided with seperated commit.
Reviewers: cedric, jpeg, raster
Reviewed By: raster
Subscribers: raster
Differential Revision: https://phab.enlightenment.org/D3831
several draw funcs keep a static Cutout_Rect *rects = NULL; variable
to cache cutout rects to avoid re-allocating them a lot etc. this is
fast and handy but we may use these from multiple threads. thats bad
.... mmmkay. so this fixes it the dirty way - makes them thread local.
:)
this fixes T3348 - the crash mentioned by @zmike
@fix
so there was/is a case where when an elm window is resized from
outside, it will happen to use the last known size (maybe old) and end
up requesting a resize to that size again itself. it basically
triggers its own resize request as a result of resize events. this
fixes that and stops the loop
@fix
so i had a separate flat theme i was working on but i just can't keep
up with changes so i'm just putting in some of the nicest bits here
slowly like nicer shadows.
@feat
after elm merge build broke with things like this enabled. this fixes
that.
i'd like to bring up one issue here. ecore_drm is not a good
abstractionlayer. it requires libdrm and other headers from system and
it should have abstracted things so the system libdrm is hidden/not
needed for build (or even perhaps at runtime and this could be rolled
into ecore_drm). this is how ecore_x is... and ecore_fb etc.
This make elementary break the modularity of the underlying layer. I haven't looked
at what is going on here, but basically if you have a wayland, a drm, whatever backend
turned on. You need elementary to be link against that ecore_* directly. This means
we are lacking in abstraction in Ecore_Evas and are dlopening to much library at
startup. This needs to be improved in the future.
I am guessing this is related to maybe DnD and C&P.
These binaries do not need the libtool library flags. This could actually lead
to problems. We already got a warning for one:
libtool: warning: '-version-info' is ignored for programs
this resolves the issue of all elm windows being created at 1x1 and
immediately resizing to another size after being shown, causing all
kinds of failures in various environments
@fix
Summary:
commit f9e6550468 Changed the RENDER_SYNC
the default behaviour (previously it was something you had to
change source code to set that way)
This leads to massive amounts of tearing with the drm and gl_drm backends,
as they no longer wait for vblank before rendering.
I've changed the env var to ECORE_EVAS_RENDER_NOSYNC and made it
non-default as it used to be. People can set the env var to disable
frame limiting instead of having to set an env var to enable it.
Frame limiting really should be the default behaviour.
Reviewers: zmike, devilhorns
Reviewed By: devilhorns
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D3829