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

Pharo4Stef pharo4Stef at free.fr
Wed Apr 2 16:55:24 EDT 2014


On 02 Apr 2014, at 14:46, J.F. Rick <self at je77.com> wrote:

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

normally it should fix the font PrObLem
can you check that you loaded the latest NB?
> 
> 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/3a3e49a1/attachment-0002.html>


More information about the Pharo-dev mailing list