After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 327175 - auto tiling of images in 3x3 grid for tiled graphics
auto tiling of images in 3x3 grid for tiled graphics
Status: RESOLVED DUPLICATE of bug 392613
Product: GIMP
Classification: Other
Component: User Interface
2.2.x
Other All
: Normal enhancement
: ---
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2006-01-16 09:29 UTC by Nick Smith
Modified: 2008-01-15 13:04 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Nick Smith 2006-01-16 09:29:42 UTC
When making textures or webpage backgrounds, it is important that they are
tilable.  What I'm suggesting is that a 3x3 grid of the active image is created
and updated after every change.  When editting in any one of the tiles, the edit
is repeated on the other tiles, even if it's not the center tile.  An option in
the menus "auto-tile" would enable the tiling.  With it disabled, you only see
one copy of your image and editting the outside area doesn't affect the image.

This way, it's easier to make tiled textures without repeatedly using the "tile"
feature to get the almost same effect for the simplest of changes.  When saving,
only the center tile is saved with the rest around it discarded in the save.
Comment 1 Raphaël Quinet 2006-01-16 16:58:27 UTC
This feature has been dicussed a couple of times on the developers mailing
list in the last years.  However, nobody has volunteered for implementing it.

Notes:
- The current protocol used between GIMP and its plug-ins does not allow the
  plug-ins to be notified when the image is updated (in fact, except for
  some special cases, the image is not supposed to be modified while a
  plug-in is running).  So this means that the tiling feature would have to
  be implemented in the GIMP image projection code.
- There are other requests for enhancements related to how the view of the
  image could be different from the image itself.  For example, providing a
  rotated view of the canvas (bug #55367).  It may be useful to implement
  both features at the same time.  Also consider bug #76096 and bug #114268.
Comment 2 Nick Smith 2006-01-17 04:54:03 UTC
I don't know C programming or any programming at that, just the very fundamentals.  The mathematics part of it and much of the technique is what I can do, however, just not code it.

When outside the graphic, a loop is created and the image width and height is constantly subtracted if greater than the image width or added if less than 0 until within the bounds of the image (from 0 to <= image width).  An edit is made to the main graphic for these pixels done one at a time.

To tile, the best I can think of is to have is to have the image "copied" and "moved" outside the "physical boundaries" and the distance moved is based on the image width and height variables.  That is, if the image was 256 pixels wide by 512 high, the tile to the top left would be first "copied" then "moved" 256 pixels left and 512 high.  The tile straight up is repeated in the same fashion, only not "moved" horizontally, but moved 512 pixels up.  The same is repeated for the tile to the top right (512 pixels up, 256 to the right) and all other tiles skipping the center tile as the center tile is the base graphic.  Updating the tiling is done by having the tiling as one function then calling the tiling function (if tile mode is active) after one of the commands is used such as the pencil, paint brush, gradient, or one of the effects like blur.

This is the technique.  Coding it is what I don't know how to do (in the correct format anyway).  Here's an example of how this would look to give an idea:

http://www.ulillillia.us/temporary/GIMPtiledtextures.png

I took a screenshot and made a few modifications to it to describe the feature and how it would look when in use.  If I were to click on the area where the pencil marker is (not the coordinates - the boundary of the main graphic is shown), an edit would be made at 230-128 or the Y position of 102 (for one of the pixels).  X, because it's in the range, doesn't change.  After the click, the graphic is updated and the tiles around it are updated as well.  Also, note the image size.  The original graphic is 128x128.  There are 384x384 pixels of space for the graphic (due to tiling) and the zoom is at 200% so it appears to be 768x768.  Hopefully this'll get you started on adding such a feature.
Comment 3 Nick Smith 2006-01-17 05:01:48 UTC
Oh, rather than calling the function after a tool is used, call it after the undo history has something new added to it since it's updated almost every time you do something.  This is a better way rather than doing it after the tool's use.  This way, rather than having the function call done for a few dozen tools, it only needs to have one function call.

Perhaps having "force update" to update the tiles manually in case the tiles aren't updated for some reason.

Since the tiles are exactly the same, only one instance of them needs to be in memory.

(Note:  not sure how to edit my comments....)
Comment 4 Michael Schumacher 2006-01-17 09:05:19 UTC
Hm, I wonder if this is something that can be done with a display filter.
Comment 5 Michael Natterer 2006-01-17 09:45:16 UTC
No, it's impossible to do with a display filter. It needs
support in the core but would not be very hard to do.
Comment 6 Sven Neumann 2007-01-06 15:16:52 UTC
It seems that what's suggested in bug #392613 would solve the same problem, only nicer. I suggest that this bug report is closed as a duplicate of bug #392613.
Comment 7 Sven Neumann 2007-01-11 18:10:11 UTC

*** This bug has been marked as a duplicate of 392613 ***