I’d say the philosophy is “whatever is convenient”. In this case, since the only user of the icon-o-matic format is icon-o-matic itself, a translator from SVG to icon-o-matic would be of no use to anyone else. Translation from SVG to HVIF may sound useful at first, but, what are applications going to do with the resulting HVIF file? The only thing you can dois rendering it to a bitmap to show it on screen. So, why not use a translator that will do that directly? And we indeed have one that does it.
Sometimes it is not even possible to convert an SVG to Icon-O-Matic or HVIF format simply because the image is too complex and has more shapes or paths than the HVIF format allows.
The Icon-O-Matic and HVIF formats are not good target formats for a translator. They are too specific.
Translators in the other direction might be useful, if there were more apps that knew hoz to import SVG files. But there aren’t that many of these yet, either.
In the end that will be the most sensible approach, as we could make a clean separation between it and the simple organizational nature of layers/groups.
Also, this will let the task be divided in two more easily approachable tickets, and opens the possibility of having one or the other, as the two things can be useful by themselves.
But… you mean transformations, right?
Though, now that I think, classifying geometric transformations as a Transformer can be more intuitive for the user (transformation, transformer), it will make good use of a UI space that is sitting mostly empty all of the time (the Transformers list), and making Contours and Strokes also shared can have a positive impact in filesize, even if a small one… hmmm…
Hmmm…
It was better than having to guess the correct perspective.
It was neutral in terms of filesize because it had to be done to things that, anyways, consisted in multiple paths.
It is more or less the same as (is going to be ) doing a perspective transformation directly to the paths inside Icon-O-Matic.
Indeed, Stippi himself had planned it that way for that all these years ago. The code had a shell of a perspective transformation and a more complete version of an affine transformation. So, the list as Stippi intended goes something like “Contour,” “Stroke,” “Perspective,” and “Transformation.” Now that, “Transformation”… It should probably be renamed to “Affine.”
Finally, gradients follow the perspective transformation. Now it’s time to clean up the code. Afterwards, I’ll need to make sure saving works and iron out various other bugs.
Here’s an interesting problem I’ve come across: how do you detect invalid perspective transforms like the one shown above? Icon-O-Matic should not try rendering these shapes since AGG likes getting into infinite loops drawing them.
The shape is somewhat interesting, though. It’s the DiskUsage icon, turned into a fractal. Here’s another image showing the fractal in higher resolution.
Edit: The fractal comes from the fact that reference images tile themselves. Disabling that, the image is mostly blank.
Ah yes, I’ve been wishing for AGG 2.6 as well. That version’s perspective transformation is more fully fleshed out. I believe this was the version Stippi wanted as well when he wrote the shell of the perspective transformer all those years ago. Unfortunately, I’m going to guess that upgrading our version of AGG would require a lot of work to fix whatever breaks as a result. Without the upgrade, I’ll likely be forced to make some changes to AGG myself.
Determining precisely how our version of AGG has diverged may be important; we’ve fixed a number of bugs (including crashes, memory faults, etc.) over the years, and we would have to check carefully that upstream has these same fixes, or contribute them back, before switching.
Exactly it is important to import the patches, the version of AGG 2.7.0 [r138] (svn) has patches from 2021, already AGG 2.6.1 based on [r132] (github) has patches from 2023, which are different structure improvements. In practice the svn repository has the latest patches in chunks, so I opened a ticket on github to add the changes to the AGG 2.6.1 repository: Add changes and fixes from svn repository version [r138] to your repository · Issue #6 · aggeom/agg-2.6 · GitHub
Doesn’t appear in Google search and so is difficult for potential contributors to find
The last commit was in 2023
It’s impossible to tell if pull requests will be accepted once the author is no longer active on the project
Doesn’t have all of the changes from the parent Github or sourceforge repositories.
Given all this, I’ll probably go with ghaerr/agg-2.6.
Later, I’ll need to figure out whether to just copies the files from the Github repository into our agg folder or use something more fancy like submodules.
So far, it’s not looking too bad. There’s been surprising little breakage. A commit changing const to non-const parameters has caused some breakage so far. Probably it would be best to just revert it.
I’ve done a little checking on this so far. It seems some of the changes we’ve made are also present upstream. I’ll still need to figure out if all of our changes have been moved over and what to do with those that haven’t been.
Edit: Yes, there are some changes that we’ve made that need to be carried over.
I don’t think we should go with any of these. None of them looks like a suitable “upstream” for us to work with; even the one from 2023 isn’t very active.
Furthermore, don’t a number of them miss patches from each other? This also ignores third-party repositories with AGG and their own modifications thereto, of which I know of a few and have them bookmarked somewhere.
IMHO we should not try to upgrade AGG before really evaluating all the different repositories.
If there are features we need to import, we can do that.
I only need some features added to the agg_trans_perspective.h. Simply replacing the current version of that file with a newer version should work.
Though by now I am close to having the newer version imported with all of our changes applied on top. The commit would look something like this commit. So maybe just continue? Though I’m not sure yet how much breakage that would cause and how much time it would take to address it.
Yes, breakage is possible; AGG changes have the potential to cause app_server crashes (many of our fixes are related to that, in fact.)
Due to there being no single definitive “upstream”, I would argue to hold off on any big changes like that, until that problem is sorted out. Or we create our own “vendored” repository, forked from another or started from scratch, and apply our own patches on that before merging anything into the tree…
If you just need a newer copy of one file, that’s easier and we should just do that for the time being, I’d say.
Not being very active is normal. Agg is a mature piece of software, besides the occasional bugfixes and new feature, it does not need much. In fact, in this situation I prefer a repository with not many changes than one with a “let’s rewrite everything” approach.
Having our changes merged with one of the repositories (doesn’t matter which one) is one step towards reducing the number of different implementations. Being able to say “we use this specific version from this repository” will reduce the work in studying what else we could merge.
Then there is the question of how to integrate it in Haiku. Normally we wouldp package it at haikuports and make the haiku build use the resulting prebuilt package. Since the picked repository is a bit “uncertain” for now (it is one of several forks of the library, and we don’t know if it will continue to be maintained), we can keep our copy of it in-tree for now, while also making sure that our changes are in that other repo as well. To me this seems better than doing our own vendored fork, oven if not as good as ressurecting the original sourceforge project.
That would be the way for Haiku to have its own fork of AGG, get what matters from the 3 patches and improvements repositories, apply solutions and patches that meet Haiku’s needs!
) doing a perspective transformation directly to the paths inside Icon-O-Matic.
