Hi, > On Jan 27, 2017, at 12:20 PM, Esteban Lorenzano <[email protected]> wrote: > > (I was going to answer a big mail but my observations/concerns are mostly > targeted by Norbert and Stef) > >> On 27 Jan 2017, at 10:49, Tudor Girba <[email protected]> wrote: >> >> Hi, >> >> Thanks for the detailed analysis. >> >> In summary, Cairo+Pango+SDL2 provide enough support to get a subset of >> Sparta working that would be equivalent with the Athens that we already >> have. In other words, with such a backend, when we would tell Sparta to use >> a blur effect, it will simply do nothing and the image environment can >> continue to work as it does now. >> >> I hope that everyone agrees that this is a reasonable fallback scenario that >> we can count on. And I think this is in line with what Stef was saying as >> well. >> >> With this in mind, we should also remember that the Moz2D backend works now >> which means that we can now focus on Brick to close the loop and provide a >> complete stack that more people can start utilizing, and we can come back to >> the alternative backend later. >> >> Does this path to action address the worry related to the future of Sparta >> backends? > > thanks Doru…. I think having a base system that works in all scenarios (even > if we miss some features) and is easy to maintain is important.
Ok, so this means that worry is addressed with this strategy. > Then you can have a different backend for complex stuff (is more or less the > same about Ronie’s Wooden… I love to have the possibility of doing the things > Ronie do with that, but I would never target to build my UI system on top of > it). Of course, choosing a technology depends on the value that you want to create with it. > Even with this simplification, I would like to know why you choose to strip a > library from a project instead testing, for example Skia (I know, Skia api is > not stable, and is C++ and C bindings are still unstable), but well… others > maybe. As I mentioned before, the stripping is only done for the text support part, not for the vector graphics support that Skia also supports. The Skia-equivalent part from Moz2D is compilable as is. > And some precisions: > > - SDL2 do allow transparent windows and windows without decorations. > https://wiki.libsdl.org/SDL_SetWindowOpacity, > https://wiki.libsdl.org/SDL_CreateWindow (and the flags section) > - Cairo do allow acceleration, we need to compile it with right backend. > - I disagree is a dead technology. Instead, is a very mature > technology… that’s why forum is not too active (even if as far as I see, it > was never too active). Yes, maybe is not in the hype, but is cool and allow > us to do very nice things. > - examples on images are slow because of how they are programmed, not because > of cairo :) Great points. It looks like we already have the right knowledge in-house :). > cheers! > Esteban > > ps: instead “not doing anything” non-suported-operations could throw a > notification (a silent one)? Sure. Doru >> >> Cheers, >> Doru >> >> >> >>> On Jan 26, 2017, at 11:45 PM, Aliaksei Syrel <[email protected]> wrote: >>> >>> Hi >>> >>> (My previous email was not a joke, I don't try to troll anyone. Let tolls >>> do their job in other places) >>> Let's forget Moz2D for a moment :) Imagine that it does not exist. It was >>> done just for fun and is even not in pharo repo. >>> (https://github.com/syrel/Moz2D). We needed something that works and it was >>> made investing just a few months of time of a single anonymous student >>> during summer exams session and vacations. >>> >>> I would like to start maybe one of the most important discussion that will >>> influence Pharo and will dictate how system will look like in a few years. >>> I invite everyone to join this discussion, especially board and consortium >>> members. Because here is where business starts. >>> >>> There are some real questions: >>> • Do we need Bloc or Morphic2 or %name your favourite framework%? >>> • How advanced and modern do you want it to be? >>> • What technology stack do we want to use for our new graphical >>> framework? >>> • What platforms and operating systems do we want to support? >>> • How flexible technology stack should be? (some parts may change in >>> the future) >>> • Who will pay for it? >>> • How many engineers can community afford? >>> • Do you know how much other systems invest in graphical frameworks? >>> • It is not a science project, isn't it? >>> Let me first put my two cents in. >>> >>> Low-level UI framework (without widgets) consists of multiple parts: >>> • Vector graphics library to render shapes (fill, stroke, path builder, >>> composition and blending operators) >>> • Font service library (to support different font formats and collect >>> information about local fonts installed in the system) >>> • Text layout engine (this is where glyph positioning magic happens, >>> link above too) >>> • Text shaping engine (for high quality text rendering, to understand >>> the problem => http://behdad.org/text/) >>> • Complex script library (to support ligatures, split glyphs and other >>> UTF8 stuff, remember >>> https://github.com/minimaxir/big-list-of-naughty-strings) >>> • Image processing library (for various image effects, like gaussian >>> blur, morphology filter, gamma, displacement map, just to name a few) >>> • Hardware acceleration. Software rendering is nice, however, modern >>> UIs are full of fancy stuff that require hardware acceleration. >>> • Window and Event management library. With support of borderless and >>> semi-transparent windows + good support of touchpad. >>> • Custom written "Glue" library that allows all components to work >>> together. Since modern libs are implemented in C++ we would need to >>> implement C wrapper and a lot of integration tests. >>> • Make the whole beast cross platform. >>> >>> Did I miss something? >>> >>> Here are some modern technologies commonly used for mentioned parts: >>> • Skia, Direct2D, CoreGraphics, Cairo >>> • Fontconfig, Freetype2 >>> • HarfBuzz >>> • Pango, OpenType >>> • Graphite2, FriBidi >>> • Imagemagic, SVG filters libraries >>> • Vulkan, OpenGL >>> • wxWidgets, QT, GTK, SDL2 >>> • todo >>> • todo >>> Luckily Pango covers bullets 2 - 5. It indeed sounds like a great idea! >>> >>> Let's assume that we stop on Cairo + Pango. According to pango.com >>> >>> The integration of Pango with Cairo (http://cairographics.org/) provides a >>> complete solution with high quality text handling and graphics rendering. >>> >>> According to the this potential technology stack we will have: >>> • Cairo for vector graphics and rendering of basic shapes >>> • Pango for text rendering >>> • SDL2 for window and events management >>> What we will not get: >>> • Support of filters; Cairo does not support gaussian blur. 3D >>> transformations, we will not be able to not implement card flip animation. >>> Never reach the same performance if using platform native frameworks (e.g. >>> Direct2D on windows). Cairo will not die, but there is zero progress. >>> • Vulkan support. Never with cairo. Pure OpenGL too (try to compile >>> cairo-gl on mac, good luck!) There is a way to compile it with quartz >>> support. As of version 2.7.9, XQuartz does not provide support for >>> high-resolution Retina displays to X11 apps, which run in pixel-doubled >>> mode on high-resolution displays. >>> (https://bugs.freedesktop.org/show_bug.cgi?id=92777). >>> • Borderless or transparent window with SDL2. Also, did you notice that >>> sdl2 window turns black/white while resizing? There is no way to get a >>> continuous window resize event with SDL2 >>> (https://bugzilla.libsdl.org/show_bug.cgi?id=2077). The issue is that >>> events stop firing while user is resizing a window because main thread is >>> blocked. Bug is already 3 years old. Indeed SDL2 is used for games, however >>> how often do gamers resize game window? >>> • Stateless API. Must have for a graphical framework like Bloc where >>> canvas state is not shared between visual elements. It means that while >>> rendering users must not clean the state of a canvas after every draw call. >>> Bloc is not my or Glenn's or Doru's personal property. We suggest, you >>> decide. It would be great if community could invest money and time in a >>> working and appropriate solution. >>> >>> P.S. If we would not care, we would agree with you instantly and even not >>> bothered ourselves trying to spend time on finding cheap solution for such >>> a complex problem. >>> >>> P.P.S Sorry for a long email :) >>> >>> Cheers, >>> Alex >>> >>> On 26 January 2017 at 21:10, Aliaksei Syrel <[email protected]> wrote: >>> Hi, >>> >>> Then we will need Cairo + SDL2 (that does not work for us) + Freetype2 (for >>> fonts) + Graphite (glyphs shaping technology in order to use them within >>> vector graphics engine) + cross platform OpenGL / Vulkan context/device >>> provider for hardware acceleration + implement Filters for effects (blur, >>> lights, color matrix filters, etc...). >>> >>> Without all those technologies bloc WILL progress, from 80's to 00's. Still >>> decades behind :) >>> >>> Cheers >>> >>> On Jan 26, 2017 20:40, "stepharong" <[email protected]> wrote: >>> I think that instead of investigating gtk (yet another library to bind and >>> carry around), >>> it would be smarter to have Sparta back-end using an accelerated Cairo + >>> pango. >>> Why? Because >>> - For example Cairo will not disappear in the future (here you will >>> tell me that it does not have all the full >>> features.... I think that Bloc should deliver Brick first and focus >>> on this because else it will stay a nice >>> experiment.) >>> - We do not have bench with an accelerated compiled version so no >>> idea if this is good enough. >>> - Cairo is about 1.5 mb vs 20Mb and it is packaged. >>> >>> I share the concerns of Esteban about the maintenance of such Mozz2d >>> bundling and he was pretty >>> clear with me, he will not maintain it nor take any responsibility about >>> pharo using it. >>> >>> So having a Cairo Sparta back-end would be a smart move. >>> Stef >>> >>> >>> >>> >>> >>> Hi, >>> >>> Thank you for the intensive set of issues you raised during the Bloc >>> presentation. I think it is worthwhile addressing them more thoroughly, so >>> let me start with the issue that seemed to have caused the most worries: >>> Sparta & Moz2D. >>> >>> Please keep in mind that while I am involved to some extent in Bloc, the >>> real credits for the current state go to Glenn and Alex. >>> >>> Moz2D (https://github.com/mozilla/moz2d, >>> https://wiki.mozilla.org/Platform/GFX/Moz2D) offers an advanced backend and >>> using it puts us on par with the rendering speed of a web browser, which is >>> a significant added value over what we have now. >>> >>> However, as it was noted, it does come with a cost due to the fact that it >>> is not available as standalone with only the features we are interested in. >>> The vector graphics part is actually buildable out of the box. However, the >>> text support needs to be extracted out of Moz2D, and this is where the >>> patching scripts are used. The patches are there only for compilation >>> purposes and not for features and they are applied automatically. You can >>> see it here: >>> https://github.com/syrel/Moz2D >>> >>> Alex updated recently the Moz2D version and it worked without problems. Of >>> course, future changes in Moz2D might imply changes in this script as well, >>> and this implies that we will need to maintain that script. And we could >>> imagine applying these patches on the trunk of Moz2D to see if they work, >>> and we can also imagine engaging with the Moz2D owners to see if we can >>> find a middle ground. >>> >>> Now, let’s put this into perspective. We are currently using Athens and the >>> Cairo backend. While Cairo is provided as a standalone library it has not >>> seen significant advances since Mozzila shifted its focus towards Moz2D. >>> So, sticking with it might not be an ideal strategy either. >>> >>> Furthermore, just like Athens, Sparta is an abstraction that allows us to >>> switch the underlying backend should we need to. Until now we did not find >>> a cross-platform backend that is as advanced and complete as Moz2D, but >>> there is no reason to think that none other will appear in the future. Skia >>> is an alternative but it is only a vector graphic engine without text >>> support, so using it would imply to have another library for the text >>> support. >>> >>> Sparta also comes with a reasonable set of tests that is aimed at testing >>> the basic Moz2D functionality to make sure that the assumptions on top of >>> which Sparta is built are correct. >>> >>> All in all, I think that the current situation is not ideal, but there is >>> already enough engineering in place to actually make it work. And I >>> definitely think that the potential it opens is rather significant. >>> >>> And, if more people look at the scripts, we might find even better and >>> cheaper ways to express it. >>> >>> Cheers, >>> Doru >>> >>> >>> -- >>> www.tudorgirba.com >>> www.feenk.com >>> >>> "We cannot reach the flow of things unless we let go." >>> >>> >>> >>> >>> >>> >>> >>> -- >>> Using Opera's mail client: http://www.opera.com/mail/ >>> >>> >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Every thing should have the right to be different." -- www.tudorgirba.com www.feenk.com "Presenting is storytelling."
