On Friday, 19 June 2015 at 14:47:10 UTC, Ola Fosheim Grøstad wrote:
> On Friday, 19 June 2015 at 14:18:49 UTC, Wyatt wrote:
>
> Do you guys have any real arguments against SVG? It is currently the most useful interchangeformat for 2D vector graphics.

You want reasons I dislike SVG?  I can address a few different levels.

It's unbelievably complex even if you reduce it to just the still-graphics parts.  This means implementing a renderer it is not even close to trivial (you need to support a huge chunk of CSS, for one thing) and rendering consistency is difficult to get right even in fairly simple situations.[1]  Fill rules, path joining, stroke scaling, markers, filters, paint order, the list goes on.  It's very byzantine.

It's DOM-based anyway, which means you can't reasonably expect good performance when manipulating it in an editor (it only pays lip-service to the concept of "human readable", so you really NEED an editor) or memory requirements.  Even just rendering it for output on a device has poor performance (I don't even know if Nvidia has even bothered putting more work into their OpenGL extension for 2D vectors).  Even relatively simple animations in SVG can peg a CPU core.

It only supports linear gradients, which makes it basically useless for artistic work unless you live in a "Modern" bubble.  There's no support for variable stroke width.  You can only define one stroke and one fill, so if you want to composite those things, you need to do a lot of duplication.  On top of that, blending can only be done through filters (which are milquetoast at best).  And text in SVG is...ugh, let's not even start.


SVG is somewhat useful if you only need simple diagrams with solid colours and you don't trust PNG for some reason.

-Wyatt

[1] http://tavmjong.free.fr/blog/?p=1257

On Friday, 19 June 2015 at 16:23:00 UTC, Wyatt wrote:
> You want reasons I dislike SVG?  I can address a few different levels.
>
> It's unbelievably complex even if you reduce it to just the still-graphics parts.  This means implementing a renderer it is not even close to trivial (you need to support a huge chunk of

Yes, it is not for end-user renderers. However, you can reduce most of the useful subset of SVG to paths and transforms.

> Even just rendering it for output on a device has poor performance

That really depends on the engine, of course, as well as the composition of the graphics, what kind of animation etc. If you know how the composition affects the renderer you can get decent performance. You obviously should not use filter effects on animations.

> It only supports linear gradients, which makes it basically useless for artistic work unless you live in a "Modern" bubble.

Oh well, what you call "Modern" I would call timeless. I think most logos can be done well in it.

>  There's no support for variable stroke width.  You can only define one stroke and one fill, so if you want to composite those things, you need to do a lot of duplication.  On top of that, blending can only be done through filters (which are milquetoast at best).  And text in SVG is...ugh, let's not even start.

Text in SVG works fine. I've used it for buttons.

I think they probably should've left out the filters and stuck with aspect that better suits CSS-theming though.

> SVG is somewhat useful if you only need simple diagrams with solid colours and you don't trust PNG for some reason.

SVG is perfectly fine for any kind of decals, logos, buttons. PNG is way more tedious.

Am Thu, 18 Jun 2015 08:05:46 +0000
schrieb "John Colvin" <john.loughran.colvin@gmail.com>:

> This appears to have involvement from all major browser vendors, which provides hope it might actually catch on properly. An llvm backend will be created which will compile to "wasm", hopefully LDC and/or SDC could glue to this.
> 
> https://www.w3.org/community/webassembly/
> 
> https://github.com/WebAssembly
> 
> In particular, see https://github.com/WebAssembly/design/blob/master/HighLevelGoals.md https://github.com/WebAssembly/design/blob/master/FAQ.md and https://github.com/WebAssembly/design/blob/master/MVP.md

I'd be more happy with code that runs outside and independently of the browser, but it seems to be the trend to move everything into virtual machines and browsers. I see the main reason notebooks have to be replaced every few years as once again <memory per open tab> * 15 >= 50% <installed system ram>.

If you have a perfectly working old notebook with Windows XP on it, I can recommend QtWeb for its low resource usage and modern-ish feature set. It is a little unstable and rough around the edges though: http://www.qtweb.net/

-- 
Marco

On Sat, 20 Jun 2015 14:06:50 +0200, Marco Leise wrote:

> If you have a perfectly working old notebook with Windows XP on it, I can recommend QtWeb for its low resource usage and modern-ish feature set. It is a little unstable and rough around the edges though: http://www.qtweb.net/

Qt+WebKit. low resource usage. you must be joking.

On Friday, 19 June 2015 at 15:13:11 UTC, Joakim wrote:
>> Hmm... Web: write once with html, css, js. Native: write three times in obj-c, java, c#. Not sure why the former should sink and not the latter.
>
> Because writing it once in HTML/CSS/JS takes you much longer than writing it in Java, while being less responsive, then you get to enjoy all the myriad ways your UI will be screwed up by the different browsers.

High DPI settings screw up native UI too if it's not pixel-precise, and ignoring user preferences is infraction, I'm afraid. And this is where web actually shines: it's designed to adapt gracefully to any user settings. Well, of course when site design strays from how web was designed to work, it runs into problems, that should be obvious.

I didn't really try to write java, but my impression is that java usually requires huge amounts of boilerplate code, while web is usually succinct.

>>> But what do they do instead of starting anew?
>>
>> Web and native are not really related, one doesn't preclude existence of the other and doesn't depend on it.
>
> That doesn't answer the rhetorical question you're responding to. In any case, they _are_ competing technologies, and one is so bad that it is manifestly losing out.

Dunno, I don't see there losses, maybe because they only happen on mobile. Yeah, you said nothing about how this is related to desktop as if it doesn't exist.

On Friday, 19 June 2015 at 15:45:20 UTC, Nick Sabalausky wrote:
> We need some sort of SVG-BSON, or something along those lines.

There's EXI.

On Sat, 20 Jun 2015 15:21:28 +0000, Kagamin wrote:

> High DPI settings screw up native UI too if it's not pixel-precise, and ignoring user preferences is infraction, I'm afraid.

/me wonders if windows still cannot into dynamic layouts. in any decent gui lib it's actually *harder* to build a gui which screws itself up on font size/window size change.


> And this is where
> web actually shines: it's designed to adapt gracefully to any user
> settings.

it was designed to ignore that fact altogether. html/css layouting is a pitiful attempt and barely usable. bwah, it can't even do normal constraints!

On Saturday, 20 June 2015 at 15:36:45 UTC, ketmar wrote:
> it was designed to ignore that fact altogether. html/css layouting is a pitiful attempt and barely usable. bwah, it can't even do normal constraints!

Hmmm, what do you mean by normal constraints?

Modern CSS provides many options, too many. CSS is no longer a simple system... So it is probably common to use javascript where CSS could have been sufficient.

On Saturday, 20 June 2015 at 15:36:45 UTC, ketmar wrote:
> On Sat, 20 Jun 2015 15:21:28 +0000, Kagamin wrote:
>
>> High DPI settings screw up native UI too if it's not pixel-precise, and ignoring user preferences is infraction, I'm afraid.
>
> /me wonders if windows still cannot into dynamic layouts. in any decent gui lib it's actually *harder* to build a gui which screws itself up on font size/window size change.

Windows API would be similar to X11, where you just specify everything in pixels and toolkits building on top of it manually do all the recomputations and layout policies, not the UI server. And then it's still not simple: with small font you can put a lot of information into a window, which simply won't fit with bigger font size, in this case web gets scrolled naturally, while native UI clunks interface and truncates strings trying to fit it into the window.

On Sat, 20 Jun 2015 16:14:43 +0000, Ola Fosheim Grøstad wrote:

> On Saturday, 20 June 2015 at 15:36:45 UTC, ketmar wrote:
>> it was designed to ignore that fact altogether. html/css layouting is a pitiful attempt and barely usable. bwah, it can't even do normal constraints!
> 
> Hmmm, what do you mean by normal constraints?

google://cassowary

that is a *real* constraint engine. what we have in css is a half-assed attemt to emulate the real engine without the engine itself.

On Sat, 20 Jun 2015 16:18:28 +0000, Kagamin wrote:

> Windows API would be similar to X11, where you just specify everything in pixels and toolkits building on top of it manually do all the recomputations and layout policies, not the UI server.

only in windows "toolkit" is built into system. and it can't do anything except pixels and stupid "dialog units".


> And then it's still not simple: with small font you can put a lot of information into a window, which simply won't fit with bigger font size, in this case web gets scrolled naturally, while native UI clunks interface and truncates strings trying to fit it into the window.

i lol'd. a typical windows rant, where "toolkits" still doesn't know about such things as "preferred size", "minimal size", and can't add scrolling if necessary, choosing to make controls smaller and smaller instead.