[Pharo-dev] [Moose-dev] Re: Re: Re: Fwd: Font problem is still there

Igor Stasenko siguctua at gmail.com
Tue Apr 1 12:27:15 EDT 2014


okay i uploaded updated configs for NativeBoost and Athens into official
repositories for these projects.

Gofer new smalltalkhubUser: 'Pharo' project: 'NativeBoost';
configuration;
load.

ConfigurationOfNativeBoost loadDevelopment.



Gofer new smalltalkhubUser: 'Pharo' project: 'Athens';
configuration;
load.

ConfigurationOfAthens loadDevelopment.


shall do the trick..

for more details see
https://pharo.fogbugz.com/f/cases/13150/Different-memory-alignment-on-different-platforms



On 28 March 2014 21:13, Pharo4Stef <pharo4Stef at free.fr> wrote:

> thanks Igor.
> I’m trying to look at the font reloading bug.
>
>
> On 28 Mar 2014, at 17:19, Igor Stasenko <siguctua at gmail.com> wrote:
>
>
> https://pharo.fogbugz.com/f/cases/13150/Different-memory-alignment-on-different-platforms
>
>
> On 28 March 2014 16:42, Igor Stasenko <siguctua at gmail.com> wrote:
>
>> so, the quick and dirty fix is to put:
>>
>> CairoGlyph class>>byteAlignment
>>
>>     NativeBoost platformId = NativeBoostConstants win32PlatformId ifTrue:
>> [  ^ 8 ].
>>     ^ super byteAlignment
>>
>> and then:
>>
>> CairoGlyph rebuildFieldAccessors
>> CairoGlyphsArray initialize
>>
>> (note you must run this snippet each time your image changes platform)..
>>
>> and i need more time to fix it for real, because it is NB issue, to
>> automatically recalculate the structs size
>> if it changes platform.. (which also means you cannot store instances of
>> struct in image which survive the session)
>> ... damn.. that's going to be complicated.
>>
>> ---
>>
>>
>>
>> On 28 March 2014 16:27, Igor Stasenko <siguctua at gmail.com> wrote:
>>
>>>
>>>
>>>
>>> On 28 March 2014 16:01, Igor Stasenko <siguctua at 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.
>>>
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko.
>>
>
>
>
> --
> Best regards,
> Igor Stasenko.
>
>
>


-- 
Best regards,
Igor Stasenko.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20140401/7a229a08/attachment-0002.html>


More information about the Pharo-dev mailing list