LWN: Comments on "The state of Linux graphic design tools in 2019 (Opensource.com)" https://lwn.net/Articles/786803/ This is a special feed containing comments posted to the individual LWN article titled "The state of Linux graphic design tools in 2019 (Opensource.com)". en-us Sun, 31 Aug 2025 21:10:06 +0000 Sun, 31 Aug 2025 21:10:06 +0000 https://www.rssboard.org/rss-specification lwn@lwn.net The state of Linux graphic design tools in 2019 (Opensource.com) https://lwn.net/Articles/787014/ https://lwn.net/Articles/787014/ BenHutchings <div class="FormattedComment"> I'd wonder if anti-virus is slowing it down. If it has been specifically tuned for Chrome and Office, but treats unknown applications as more suspicious, that could explain it.<br> </div> Mon, 29 Apr 2019 14:15:49 +0000 The state of Linux graphic design tools in 2019 (Opensource.com) https://lwn.net/Articles/786999/ https://lwn.net/Articles/786999/ gfernandes <div class="FormattedComment"> The Windows API (and behaviour) *are* necessarily different from the Linux API.<br> <p> ...<br> <p> My advice is: rather than trying to *drive* a car up a ski slope, take the ski lift, and get some skis.<br> </div> Mon, 29 Apr 2019 07:27:05 +0000 The state of Linux graphic design tools in 2019 (Opensource.com) https://lwn.net/Articles/786998/ https://lwn.net/Articles/786998/ gfernandes <div class="FormattedComment"> There are always going to be broken expectations for a complex application written for one API, ported to another.<br> <p> The Windows API (and behaviour) address necessarily different from the Linux API. This, in itself, would be sufficient to explain at least some of the differences.<br> <p> If I were you, I'd make that machine dual boot to Linux, and use the same tools there. Native behaviour is bound to be better.<br> <p> These days, you can create a bootable USB with persistent memory, to install initiators applications you need.<br> <p> My advice is: rather than trying to derive a car up a ski slope, take the ski lift, and get some skis.<br> </div> Mon, 29 Apr 2019 07:24:58 +0000 The state of Linux graphic design tools in 2019 (Opensource.com) https://lwn.net/Articles/786885/ https://lwn.net/Articles/786885/ ledow <div class="FormattedComment"> Oh, and Inkscape grows up to 300Mb RAM usage on initial import, maxes out a single CPU for all that time, but negligible disk activity.<br> <p> Whatever's it's doing, it's choosing a very slow path on Windows to do it.<br> </div> Fri, 26 Apr 2019 13:09:48 +0000 The state of Linux graphic design tools in 2019 (Opensource.com) https://lwn.net/Articles/786865/ https://lwn.net/Articles/786865/ ledow <div class="FormattedComment"> Unfortunately not.<br> <p> But, for instance on an 8Gb with SSD machine:<br> <p> - 2 minutes to start up from a cached icon clicking (Outlook starts cold in... 10 seconds with a huge mailbox on the same machine, so it's hardly a slug).<br> - Import a 600Kb PDF (which is just a very, very sparse vector-drawn map from consisting of maybe a few dozens of individual lines) - 2 minutes, 10 seconds.<br> - To then select and "Ungroup" that group of (presumably now Inkscape) vectors - another 45 seconds.<br> - That document is then very sluggish to work in and groups/ungroups/moves of objects can take ten-15 seconds of "Not Responding" Inkscape to do anything. And it's not peculiar to those documents, I can import a small logo SVG and have the same happen.<br> <p> Windows 8.1, normal machines, nothing fancy but they don't struggle with Chrome or Office or anything else.<br> <p> But when it takes 5+ minutes to open a document, and then 30-40 seconds every time you attempt something even mildly taxing, it quickly becomes tedious.<br> </div> Fri, 26 Apr 2019 13:03:01 +0000 The state of Linux graphic design tools in 2019 (Opensource.com) https://lwn.net/Articles/786847/ https://lwn.net/Articles/786847/ sandsmark <div class="FormattedComment"> <font class="QuotedText">&gt; For instance, in Inkscape, a simple vector map (which is supplied as PDF originally, probably one hundred or so individual lines) descends into 20-30 minute all-CPU churning on import and conversion</font><br> <p> I suspect that this is more related to the type of elements than the number of lines (as well as the number of points in the lines). As I/we've learned here (at reMarkable) PDF is a huge pain to work with in general (especially if you want to do more than just using e. g. pdfium or poppler to rasterize out pages for you), and Inkscape works in SVG which has become a crazily complex format in general, so I imagine converting from PDF to SVG gets painful quickly.<br> <p> That said, I haven't seen anything like this in Inkscape here on Linux, and I've been using Inkscape a lot to debug the PDF stuff we've been doing, and Sletta hasn't complained about it on macos either, so it really sounds like a bug specific to Windows.<br> <p> If you're able to share one of these files, I think the Inkscape developers would be very grateful to have it as a testcase.<br> </div> Fri, 26 Apr 2019 09:30:52 +0000 The state of Linux graphic design tools in 2019 (Opensource.com) https://lwn.net/Articles/786838/ https://lwn.net/Articles/786838/ ledow <div class="FormattedComment"> Is it just me that finds that Scribus on Windows is very buggy and crashes a lot, and Inkscape is incredibly slow on Windows for even the simplest of tasks?<br> <p> I update both religiously and, because we don't have other DTP tools or SVG editors in work, I end up using them quite a lot.<br> <p> For instance, in Inkscape, a simple vector map (which is supplied as PDF originally, probably one hundred or so individual lines) descends into 20-30 minute all-CPU churning on import and conversion (without any indication of progress for the most part), then once it's converted (presumably to SVG) any sort of ungroup operation takes similar amounts of time (and it usually takes several such operations to actually get to individual vectors such that you can start pruning, moving and recombining them). Hell, we have a corporate logo supplied as EPS, SVG, etc. and just playing about with that (masking off a region to make it transparent, etc.) can be a struggle.<br> <p> That's on a computer with 8Gb, an SSD, etc. and no significant disk activity all that time. I wish I could say it was only that computer but even at home on a 6-core, 12Gb gaming laptop, I have the same problem.<br> <p> I honestly wouldn't use them if there was a decent, free SVG editor on Windows that actually worked vaguely nicely.<br> <p> The last such product I held as a good example of the kind was the Serif Pageplus/Drawplus products (which don't exist any more, only "Affinity" which is only in beta) - cheap/free, featureful, but even the v4/v5 of those products back in the Windows 95 days felt a billion times faster and smoother than Scribus/Inkscape on a modern Windows machine.<br> <p> Hell, you know there's something wrong with other software when LibreOffice tools feel positively zoomy nowadays.<br> </div> Fri, 26 Apr 2019 07:53:02 +0000 The state of Linux graphic design tools in 2019 (Opensource.com) https://lwn.net/Articles/786840/ https://lwn.net/Articles/786840/ mfuzzey <div class="FormattedComment"> At the end of that article it said<br> <p> <font class="QuotedText">&gt;But what about (cough) running Adobe on Wine? (cough)</font><br> <font class="QuotedText">&gt;Yeah, I'm sure you can do it. But this isn't about breaking end user license agreements. I'm not about that life. This is about the efficacy of real, open source, design &gt;software running available on open source platforms, right now.</font><br> <p> While I totally agree using real open source software is much better does it really break Adobe's EULA to run it on Wine? (assuming you have a properly licensed copy of course).<br> <p> </div> Fri, 26 Apr 2019 07:49:19 +0000 The state of Linux graphic design tools in 2019 (Opensource.com) https://lwn.net/Articles/786835/ https://lwn.net/Articles/786835/ rsidd There are wireframe tools for linux, eg <A HREF="https://pencil.evolus.vn/">Pencil</A> and <A HREF="https://wireflow.co/">Wireflow</A>. I have no idea how good they are but they are easy enough to find online, and if it were so important to the author, I feel he should have given them a spin. <P> As for the other tools, yes they are all excellent. Krita deserved a mention too: it's a somewhat different category from Gimp, geared more towards art than photo-editing. But the author admits he got his start with Inkscape and Gimp, which makes him a bit different from the typical graphic artist who may not give such high marks to those tools... Fri, 26 Apr 2019 05:38:26 +0000