Translate THOUGHTS to english

[pulkomandy]

It would be nice to have this in english to see where things are headed.

[stippi]

Yes, this should be the next thing I do.

[bitigchi]

Took a shot with Google Translate. Looks accurate enough, but will not open a PR, since it's machine translation anyway.

Render at zoom level

Zooming in / out are two completely different things. When you zoom in, you have to calculate a small section of the document in the original resolution and display it enlarged. When you are zoomed out, you have to calculate a lot fewer pixels than required for the original resolution. If you were to calculate all pixels and then only display them with gaps, the result would also be an ugly display, as it is much easier to pretend that the original resolution is smaller and the document is calculated that way. Photoshop seems to filter some zoom levels (25%, 50%), but with the proposed approach, each zoom level would be virtually "perfectly filtered".

Bitmaps and caches in blocks

It makes sense to cache the document view for a certain object level. Perhaps it would be an advantage to divide this cache into even blocks (sections of the view), each of which can contain a different object level. If you need a (part of a) cache block when rendering, but you find that it is out of date, you simply expand the rendering by the area of ​​the entire block so that the block is completely valid the next time you render.

Where are the caches in the object tree, also at the nodes?

To what extent should there be bitmap data swapped out on the hard drive?

BitmapData
-> Representation of bitmap data
-> only one global instance of the same data
-> referenced

BitmapManager
-> Managed BitmapData objects
-> Only one instance across the application

BitmapObject
-> new objects create new BitmapData instance and transfer to
BitmapManager
-> references BitmapData
-> actually a rectangle object with bitmap filling

Application-wide "FillCache", could also contain BitmapManager. Bitmaps are always used together, however.

Fill
FillColor
FillGradient
FillBitmap

A "style" is not the filling like with Icon-O-Matic, but a kind of container for different properties. Properties that have not been set could be inherited hierarchically.

Objects can have a private style or the style can be made public and then used by other objects. The changes to the style by any of the objects will be visible in all of the objects.

As in Icon-O-Matic, you could not only make global styles available, but also fills and paths. Optional, however, not by default for new objects.

Fills must optionally support an alpha channel (bitmap). At least in such a way that you can click into the picture with the filler and then fill not only with one color, but also with all other types of fill.

Fill colors should also be able to appear as a "shade" of another color. If the main color is deleted, a confirmation dialog appears asking whether all shades should be converted to normal colors. Alternatively, you could also manage an additional property in the style, which ensures that a filling is darkened or otherwise changed.

Layouting:
Layouting means that the object tree is traversed and dependencies are finally resolved. For example, an object size could depend on the current font size, with the font only being set in a superordinate object. Since the tools will also need ready-made "layouted" object parameters, it makes sense to perform the layout on the original document. To do this, changes to an object would have to indicate that a layout of the subtree is necessary. Alternatively, absolute parameters in the original object tree could always be resolved live, but the explicit layout process could make it easier to know the regions to re-render. In principle, a layout of the snapshots is also necessary, asynchronously before each rendering process. For example, the current zoom and scroll offset can flow into the global matrices, which should be left out in the original document.

Extend PropertyObject Interface:
-> Query for the number of "PropertyObjects" or "PropertyCategory" or
"Sub-PropertyObject" (nested PropertyObjects?)
-> collapsible sections for each individual PropertyCategory in ListView
-> PropertyCategory supports adding properties.
-> For example, the style of an object is then in the same
PropertyListView can be displayed and edited.

Alternative view for the layers and objects: The view only shows the objects of the current layer. When you double-click on a layer, the view shifts to the left by its width (with fast scrolling effect) and now shows the objects of the clicked layer. You can move to the right (in / lower) and left (out / higher) in the hierarchy using arrow buttons, there could also be a "breadcrumb" control so that you can jump in the current path. This could run from top to bottom. The path changes when you explicitly double-click on a layer, but otherwise remains stable if the user only briefly jumps back and forth between the layers.

Slice tool:
Slices are rectangular areas on the screen that the user can create, define and name. When exporting you can export all slices, which exports the area under the name. The target folder is selected and perhaps a file name, where a wildcard is replaced with the name of the respective slice.

[stippi]

Hm... not quite. I'll give it a shot with deepl..

[stippi]

Render with zoom level

Zooming in/out are two completely different pairs of shoes. When zoomed in, a small section of the document has to be calculated and enlarged in original resolution. When zoomed out, you have to calculate much fewer pixels than required for the original resolution. If you calculate all pixels and then display them incompletely, the result would also be an ugly display, so it is much easier to pretend that the original resolution is smaller and calculate the document that way. Photoshop seems to filter some zoom levels (25%, 50%), but with the proposed approach, each zoom level would be "perfectly filtered".

Blockwise bitmaps and caches

It is useful to cache the document view to a certain object level. Perhaps it would be advantageous to divide this cache into equal blocks (sections of the view), each of which can contain a different object level. If you need a (part of one) cache block when rendering, but find that it is outdated, simply extend the rendering by the area of the entire block, so that the block is completely valid for the next rendering.

At which position are the caches in the object tree, also at the nodes?

To what extent should there be bitmap data stored on disk?

Bitmap data
-> Representation of bitmap data
-> only one global instance of the same data
-> referenceable

BitmapManager
-> Managed BitmapData Objects
-> Only one instance application-wide

Bitmap object
-> new objects create a new BitmapData instance and pass it to
BitmapManager
-> references BitmapData
-> actually rectangular object with bitmap filling

Application-wide "FillCache", could also include BitmapManager. However, bitmaps are always shared.

Fill
FillColor
FillGradient
FillBitmap

A "style" is not a filling like Icon-O-Matic, but a kind of container for different properties. Properties that are not set could be inherited hierarchically.

Objects can have a private style or the style can become public and then be used by other objects. Changes to the style by any of the objects are visible in all objects.

Like in Icon-O-Matic not only global styles but also fills and paths could be made available. However, this is optional, not standard for new objects.

Fillings must optionally support an alpha channel (bitmap). At least in a way that you can click into the image with the fill bucket and then fill not only with one color, but with all other fill types as well.

Fill colors should also be able to appear as "shading" of another color. If the main color is deleted, a confirmation dialog appears, asking if all shades should be converted to normal colors. Alternatively, you could also manage an additional property in the style, which makes sure that a fill is darkened or otherwise modified.

Layouting:
Layouting means that the object tree is traversed and dependencies are finally resolved. For example, an object size could depend on the current font size, where the font is only set in a parent object. Since the tools will also need ready-made "laid out" object parameters, it is useful to do the layout on the original document. To do so, changes to an object would have to indicate that a layout requires the subtree. Alternatively, absolute parameters in the original object tree could always be resolved live, but the explicit layout process could make it easier to know the regions for re-rendering. In principle, a layout of the snapshots is also necessary, asynchronously before each rendering process. For example, the current zoom and scroll offset can be included in the global matrices, which should be left out in the original document.

Extend PropertyObject Interface:
-> Query for number of "PropertyObjects" or "PropertyCategory" or
"Sub-PropertyObject" (nested PropertyObjects?)
-> collapsible sections for each individual PropertyCategory in ListView
-> PropertyCategory supports adding properties.
-> For example, the style of an object is then displayed in the same
PropertyListView can be displayed and edited.

Alternative view for layers and objects: This view shows only the objects of the current layer. When double-clicking on a layer, the view moves to the left by its width (with fast scroll effect) and now shows the objects of the clicked layer. You can move right (in/deeper) and left (out/up) in the hierarchy using arrow buttons, additionally there could be a "Breadcrumb" control, so you can jump in the current path. This could run from top to bottom. The path changes by explicitly double-clicking on a layer, but otherwise remains stable if the user jumps only briefly between layers.

Slice tool:
Slices are rectangular areas on the screen that the user can create, define and name. When exporting, all slices can be exported, which exports the area under the name. The destination folder and perhaps a file name is selected, where a wildcard with the name of the respective slice is replaced.