On 28 March 2014 16:01, Igor Stasenko <siguctua@gmail.com> wrote:

Ookkayy..

so, current status:

��- finally we got an agreement that big red square because of font loading issues and font rendering artifacts is two separate issues.

Thanks!

- i am not going to address font-loading issue here and now.. (because we spent time on it earlier today with Stef already and you should have the report on it in separate mail).

- we seem to be agreed that it is best to use same (up-to-date version) of software when reporting issues to work on them. Thanks again. :)

- while on linux and mac things seem to be working fine, i can confirm that there is rendering artifacts (same as reported by Vincent) on Windows.

so i going to explore what causing this problem..

... and found the cause:

On windows, for unknown reason, the structure (cairo_glyph_t) uses different memory space alignment than on mac and linux

fieldsDesc
������ ^ #(
������ ulong�������������� index;
������ double���������������������������� x;
������ double���������������������������� y;
������ )

on mac and linux , the size of this structure in memory = 4 + 8 + 8 = 20 bytes,
on windows, however, due to 8-byte alignment, it is�� 4 + 8 + 8 + (4 alignment) bytes...

��

this causing the effect that if you copy array of glyphs in memory,
it does not copying whole array by slightly less�� (because it uses wrong struct size which is smaller than it is)..

and because of that, you got weird artefacts at the tail of string, replaced by misplaced/invalid characters etc..
because it is basically read from uninitialized part of memory with random data.

i going to fix structure alignment for windows from default 4 bytes to 8 bytes..

but this is not very good news.. because this affecting many things... (as you can imagine, not only cairo/athens working with external structures, which need to be properly aligned).

--
Best regards,
Igor Stasenko.