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.