[ANN] Sparta v1.1

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
104 messages Options
1234 ... 6
Reply | Threaded
Open this post in threaded view
|

[ANN] Sparta v1.1

Aliaksei Syrel
Hi

I am happy to announce the release of Sparta v1.1 for Pharo 6.

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)
Inline images 2

(measurement)
Inline images 1


Cheers,
Alex
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Sparta v1.1

abergel
This is impressive! We are moving right!

Alexandre


On Oct 19, 2016, at 1:06 PM, Aliaksei Syrel <[hidden email]> wrote:

Hi

I am happy to announce the release of Sparta v1.1 for Pharo 6.

It can be bootstrapped with the following script:

Metacello new
  baseline: 'Sparta';
  repository: '<a href="github://syrel/" class="">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)
<sparta-text-haiku.png>

(measurement)
<sparta-text-measurement.png>


Cheers,
Alex

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Sparta v1.1

Tudor Girba-2
In reply to this post by Aliaksei Syrel
Great work!

Doru



> On Oct 19, 2016, at 5:06 PM, Aliaksei Syrel <[hidden email]> wrote:
>
> 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)
> <sparta-text-haiku.png>
>
> (measurement)
> <sparta-text-measurement.png>
>
>
> Cheers,
> Alex

--
www.tudorgirba.com
www.feenk.com

"We are all great at making mistakes."









Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Sparta v1.1

NorbertHartl
In reply to this post by Aliaksei Syrel
Great! Seems to be the case that we need to take the 64bit border!!

Norbert

Am 19.10.2016 um 18:06 schrieb Aliaksei Syrel <[hidden email]>:

Hi

I am happy to announce the release of Sparta v1.1 for Pharo 6.

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)
<sparta-text-haiku.png>

(measurement)
<sparta-text-measurement.png>


Cheers,
Alex
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Sparta v1.1

stepharo
In reply to this post by Aliaksei Syrel

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.

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)
Inline images 2
(measurement)
Inline images 1
Cheers,
Alex
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Sparta v1.1

Denis Kudriashov
In reply to this post by Aliaksei Syrel
Super!!!

Is latest Bloc uses Sparta?

2016-10-19 18:06 GMT+02:00 Aliaksei Syrel <[hidden email]>:
Hi

I am happy to announce the release of Sparta v1.1 for Pharo 6.

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)
Inline images 2

(measurement)
Inline images 1


Cheers,
Alex

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Sparta v1.1

Denis Kudriashov
In reply to this post by Aliaksei Syrel

2016-10-19 18:06 GMT+02:00 Aliaksei Syrel <[hidden email]>:
Examples are on class side of: MozExamples, MozTextExamples

I found 18+ example :)))
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Sparta v1.1

Denis Kudriashov
In reply to this post by Aliaksei Syrel

2016-10-19 18:06 GMT+02:00 Aliaksei Syrel <[hidden email]>:
 - Added initial text support, for instance rendering and high precision measurement.

I look at code and it seems you implemented another one new text model? Why you not use TxText?
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Sparta v1.1

Glenn Cavarlé
In reply to this post by Denis Kudriashov
Good job Alex!
Yes, the development version of Bloc is already based on Sparta.
The stable version 0.10.1 is the last version with Athens support.

Cheers,
Glenn.
Glenn Cavarlé
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Sparta v1.1

Aliaksei Syrel
In reply to this post by stepharo
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" <[hidden email]> 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.

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)
Inline images 2
(measurement)
Inline images 1
Cheers,
Alex
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Sparta v1.1

Aliaksei Syrel
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 <[hidden email]> 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" <[hidden email]> 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.

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)
Inline images 2
(measurement)
Inline images 1
Cheers,
Alex

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Sparta v1.1

Denis Kudriashov
Hi Aliaksei

2016-10-20 9:16 GMT+02:00 Aliaksei Syrel <[hidden email]>:
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:

Could you explain what is wrong with TxText model to achieve this? (I comment bellow each point). And do you have any links to understand what moldable text editor means?
 
  - support of very large files (gigabytes)

TxText-Athens implement text morph to show big text models. Maybe the way how it is designed is not suitable for Sparta and Bloc. Then I will understand if you will just drop away this code and build Bloc/Sparta optimized version but on top of same text model.
If you talk about showing files it is not enough of course because full text model needs to be loaded from file which is not scale when file size is huge.

But TxText model looks very smart to provide lazy logic where text elements are loaded and built by demand. And it looks much easy to do than with Rope kind model. TxText is linked list of elements. No problem to build them lazily.
 
  - multithreading (styling, syntax highlighting in background)

I am really interesting how it could be done and why Rope model is better than TxText model from this perspective.

Styling is just editing text by splitting elements and marking them with specific attributes. How to do it in background when somebody could edit text in same time? 
Rope model or TxText model is complex structure. It is quite difficult to make it safe for concurrency. 
 
     => text model has to be immutable

So solution is to not modify existing model. For example we could extract full string from text, build new model and install it into widget. But here is same problem original copy could be modified by user while new model is built. What to do then? 
I actually made conclusion that background styling is bad idea. (in the way when we show text to user and only then start styling it)

  - fast access by index (for styling; parser returns Tokens with indices)

Ok. Here Rope model works better then TxText. But is it really important case? 
For your styling example it is possible to solve it differently. Imaging if parser will produce text model itself. So any parse node will not point to token string but to text element inside text model. And then styler will just mark them with attributes directly. No index access will be needed. And such approach could lead to very interesting things. Imaging that source code is text model where elements are marked by AST-nodes (as attributes).
 
  - optimised for sparta (use all amazing text features provided by Moz2D)

I see same kind of text attributes in Sparta text as in TxText. What else you added to text to cover specific Sparta features and why attributes was not enough for this?


Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Sparta v1.1

Denis Kudriashov
In reply to this post by Aliaksei Syrel
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 <[hidden email]>:
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 <[hidden email]> 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" <[hidden email]> 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.

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)
Inline images 2
(measurement)
Inline images 1
Cheers,
Alex


Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Sparta v1.1

Denis Kudriashov
In reply to this post by Aliaksei Syrel
2016-10-20 9:07 GMT+02:00 Aliaksei Syrel <[hidden email]>:
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).

Also imaging that we will remove Cairo, Athens, Fonts from image, font plugin from VM. Also Morphic and old Canvas. I expect Morphic is much bigger then Bloc. And at some point bitblt stuff from image and VM.
I am sure at the end new clean solutions will provide much lesser image and VM size.
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Sparta v1.1

Denis Kudriashov
In reply to this post by Glenn Cavarlé

2016-10-20 1:15 GMT+02:00 Glenn Cavarlé <[hidden email]>:
Good job Alex!
Yes, the development version of Bloc is already based on Sparta.
The stable version 0.10.1 is the last version with Athens support.

What the repository for Bloc?
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Sparta v1.1

Aliaksei Syrel
Hi Denis

Thanks for your questions! They are important.
Unfortunately, I didn't have time today to perform a detailed comparison and stress test of txtext model.
I will answer tomorrow :)

Cheers,
Alex

On 20 October 2016 at 22:17, Denis Kudriashov <[hidden email]> wrote:

2016-10-20 1:15 GMT+02:00 Glenn Cavarlé <[hidden email]>:
Good job Alex!
Yes, the development version of Bloc is already based on Sparta.
The stable version 0.10.1 is the last version with Athens support.

What the repository for Bloc?

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Sparta v1.1

Sean P. DeNigris
Administrator
In reply to this post by Denis Kudriashov
Denis Kudriashov wrote
I look at code and it seems you implemented another one new text model? Why
you not use TxText?
Argh. I know it's bad form to complain about gifts, but at the rate we reinvent the wheel, I often fear that I will be retired from programming before we have a sane text model :/
Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Sparta v1.1

NorbertHartl


Am 21.10.2016 um 04:00 schrieb Sean P. DeNigris <[hidden email]>:

Denis Kudriashov wrote
I look at code and it seems you implemented another one new text model?
Why
you not use TxText?

Argh. I know it's bad form to complain about gifts, but at the rate we
reinvent the wheel, I often fear that I will be retired from programming
before we have a sane text model :/

It has a name and we should fight it:


Norbert

-----
Cheers,
Sean
--
View this message in context: http://forum.world.st/ANN-Sparta-v1-1-tp4919394p4919570.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Sparta v1.1

Stephan Eggermont-3
In reply to this post by Aliaksei Syrel
On 19/10/16 18:06, Aliaksei Syrel wrote:
> Examples are on class side of: MozExamples, MozTextExamples

Error: could not coerce arguments

primSetAttributeEnum: anEnumValue index: anIndex

        ^ self ffiCall: #(void moz2d_filter_node_set_attribute_int(self,
FFIExternalEnumeration anIndex, FFIExternalEnumeration anEnumValue))

60265, Vm 497, Mac, 10.10.5

Stephan


Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Sparta v1.1

Stephan Eggermont-3
In reply to this post by Sean P. DeNigris
On 21/10/16 04:00, Sean P. DeNigris wrote:
> Denis Kudriashov wrote
>> I look at code and it seems you implemented another one new text model?
>> Why
>> you not use TxText?
>
> Argh. I know it's bad form to complain about gifts, but at the rate we
> reinvent the wheel, I often fear that I will be retired from programming
> before we have a sane text model :/

There seem to be different ideas about what a sane text model is. I'm
only interested in a high-quality text editing model, extendable to
support hyphenation, kerning, line-breaking, multiple-column page
layout, tables, foot- and endnotes, styling on more than a character
span basis. In particular I will not use a model that is only suitable
for line-based editing. That is a dead-end. It is fine to have only
trivial implementations of those at first,  but the abstractions need to
be there.

Stephan




1234 ... 6