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

J.F. Rick self at je77.com
Wed Apr 2 08:46:21 EDT 2014


Is this supposed to fix the font rendering problem or some other font
problem? I tried it and it doesn't seem to help the rendering problem.

Cheers,

Jeff


On Tue, Apr 1, 2014 at 6:27 PM, Igor Stasenko <siguctua at gmail.com> wrote:

> 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.
>



-- 
Jochen "Jeff" Rick, Ph.D.
http://www.je77.com/
Skype ID: jochenrick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20140402/7e61368d/attachment-0002.html>


More information about the Pharo-dev mailing list