I also wondering about Sparta approach for text layout/rendering. You implemented old text morph idea: layout text while render it. Why you choose it? With such approach all computed information about text layout is lost when text is rendered. You can't reuse it for text navigation/editing. And anytime redraw is needed all these objects will be recreated again. Many garbage for any redraw. And many garbage for text navigation, for any cursor movement. Am I wrong about it? 2016-10-20 9:16 GMT+02:00 Aliaksei Syrel <alex.syrel@gmail.com>:
Hi Denis
I look at code and it seems you implemented another one new text model?
Why you not use TxText?
Was tough decision :) We decided (in GT) that next moldable tool should be a "Moldable Text Editor for Pharo". Here are some requirement that must be full-filled by text editor: - support of very large files (gigabytes) - multithreading (styling, syntax highlighting in background) => text model has to be immutable - fast access by index (for styling; parser returns Tokens with indices) - optimised for sparta (use all amazing text features provided by Moz2D)
Cheers, Alex
On 20 October 2016 at 09:07, Aliaksei Syrel <alex.syrel@gmail.com> wrote:
Hi Stéphane
Indeed, build is broken :) Yesterday I took a very brief look at bloc and can confirm that development version is loadable in Pharo 6 and is completely Sparta based. (all examples work for me)
You are right, live environment on embedded systems is great goal to achieve. Sparta must not prevent pharo from getting there. It is true that plugin is relatively big (windows 7mb, osx 15mb, linux 18mb). However, it is all-in-one build and size can be reduced dramatically.
As I understand, Pharo for PC should not make any assumptions about user's hardware. If gpu accelerated backend can not be used there should be still a performant fallback backend which also needs a fallback that is guaranteed to work even on Personal Calculators. (Taschenrechner). That is why library is so big. For example for mac and windows Sparta is shipped with 3 (!) backends that together build fallback chain, for instance on windows: direct2d1.1, skia, cairo. Compiling library for mac without Skia reduces binary size from 15mb to 10mb. Removing GL package and leaving only software backends may reduce size even more.
It is a bit different on embedded systems, since hardware configuration is already known and there is no need to have so many fallback backends. Library itself allows developers to add new exotic backends quite easily.
Let's take Pharo6 for mac. It is shipped with the following libs: Cairo (1.4mb) + Pixman (2.8mb) + Freetype (0.8mb) = 5mb
Moz2D is self contained and does not require any additional libs. Moz2D = 15mb, Moz2D without Skia = 10mb. Moz2D without Skia and GL = ? (estimate around 6-7mb).
As you can see we get almost the same numbers :)
Cheers Alex
On Oct 19, 2016 22:16, "stepharo" <stepharo@free.fr> wrote:
Hi Aliaksei
It looks gorgeous. I tried to launch the Bloc image from the CI and it crashes during startup on my mac. I reported that to Glenn and Alain but so far I simply cannot see Bloc code. Is it working for you? I mean is it me that is using the wrong VM.
Then I have a question:
- do you think that we can have a fallback in terms of back end for the case where we could like to run Pharo on coffee machines but get a live environment on such machines? This is related to the discussions we got this summer about the memory footprint that Moz2D will put on us.
I do not mean that we must have one but I think that this is important to check because we can say that Pharo is small but if we need 20 mb libraries for rendering there are some cases where this can kill its usage.
Stef Le 19/10/16 à 18:06, Aliaksei Syrel a écrit :
Hi
I am happy to announce the release of Sparta v1.1 for Pharo 6. https://github.com/syrel/Sparta/tree/v1.1
It can be bootstrapped with the following script:
Metacello new baseline: 'Sparta'; repository: 'github://syrel/sparta:v1.1/src'; load: #file:core
Examples are on class side of: MozExamples, MozTextExamples (*for linux users:* if you use 32bit pharo on 64bit linux, sparta will not work, since 32bit plugin depends on 32bit GTK which conflicts with 64bit GTK. Either use 32bit linux or 64bit pharo. I tested sparta with 64bit vm on mac and linux - it works, but some features fail because FFI is not ready) Release of v1.1 is focused on hardware acceleration, windows support and text rendering. *What is new:* - Default backends on all platforms changed from software to hardware accelerated. - Now also works on Windows! Default backend is Direct2D for drawings and DirectWrite for text. On multi-gpu machines per-app-default setting is respected. In case of Nvidia it can be changed in nvidia control panel. Sparta is x2 faster on discrete gpu than on integrated one. - Added initial text support, for instance rendering and high precision measurement. - Per-platform settings system is now image based. Allows to enable/disable hardware acceleration, change default backends, change font-mappings tables. Some text examples: (rendering) [image: Inline images 2] (measurement) [image: Inline images 1] Cheers, Alex
