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 782751 - Spacing Brush Performance with Image Precision on GIMP 2.9 Git Master | 8i, 16i, 16f, 32i and 32f
Spacing Brush Performance with Image Precision on GIMP 2.9 Git Master | 8i, 1...
Status: RESOLVED DUPLICATE of bug 694917
Product: GIMP
Classification: Other
Component: General
git master
Other Linux
: Normal normal
: ---
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2017-05-17 18:06 UTC by jose americo gobbo
Modified: 2018-04-04 00:52 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Performance Chart of Spacing Brush ranges. (22.56 KB, image/svg+xml)
2017-05-17 18:06 UTC, jose americo gobbo
Details
Spreadsheet of my tests - spacing brush performance (36.65 KB, application/vnd.oasis.opendocument.spreadsheet)
2017-05-17 18:08 UTC, jose americo gobbo
Details
Performance Chart of Spacing Brush ranges - image (37.06 KB, image/png)
2017-05-17 18:09 UTC, jose americo gobbo
Details
two important brushes used in this test (150.85 KB, application/zip)
2017-05-17 18:13 UTC, jose americo gobbo
Details
Add a Comparison with Acrylic 04 brush in the GIMP 2.8.22 (same conditions). (25.41 KB, image/svg+xml)
2017-05-21 14:14 UTC, jose americo gobbo
Details
Spreadsheet of my tests - spacing brush performance (GIMP 2.8.22 > 2.9) (36.19 KB, application/vnd.oasis.opendocument.spreadsheet)
2017-05-21 14:34 UTC, jose americo gobbo
Details
Comparison brush spacing performance between GIMP 2.8.22 and 2.9.5 (last git master) (16.57 KB, image/svg+xml)
2017-06-01 19:53 UTC, jose americo gobbo
Details
Comparison brush spacing performance between GIMP 2.8.22 and 2.9.5 (last git master) (16.03 KB, image/svg+xml)
2017-06-01 20:43 UTC, jose americo gobbo
Details
Spacing brush performance (vbr) with different image precisions (178.55 KB, image/png)
2017-06-07 17:43 UTC, jose americo gobbo
Details

Description jose americo gobbo 2017-05-17 18:06:44 UTC
Created attachment 352040 [details]
Performance Chart of Spacing Brush ranges.

Brush Spacing Performance of GIMP brushes
---s
I have made some performance tests on the last GIMP 2.9 git master with spacing brush parameter (tool options).
The test was made with an A3 format, 300 ppi using Paintbrush tool with Ctrl+Shift to paint the strokes.

I have select some brushes with different dimensions (from 500 to 71 px), types (vbr and rasters) and weights (from 76 bytes to 3.4MB). The brushes used were essentially of default set, only a very weight brush (buliga-factory with 3.4 MB! is a my experimental brush) only to see if the the behavior is dependent of layers number.

The time range resulting in this test to all brushes, it had variations between 1~13 seconds (see the chart).

---
Tool Options settings

Size used in all tests: 500 px
Spacing range tested was: 20, 10, 5, 2, 1.
Opacity: 100%
Hardness: 100% > Default
Force: 50% > Default
No dynamics

---
Schema of brushes used

buliga-factory (500x458), 15 layers, GIH, 3.4MB
Acrylic 04 (300x300), 4 layers, GIH, 176.7kB
Texture Hose 03 (300x300), 4 layers, GIH, 360,2kB
Charcoal 02 (128x128), GBR, 16.4kB
2. Hardness 100 (71x71), VBR, 76 bytes

I have noted that the delay apparently doesn't relationed with weight essentially... the buliga-factory with spacing=1 spent circa 12s to draw a stroke but is very similar to Texture Hose 03, and this last has a weight 10 times minor of the buliga-factory.

Is possible improve a bit the performance?
Comment 1 jose americo gobbo 2017-05-17 18:08:10 UTC
Created attachment 352041 [details]
Spreadsheet of my tests - spacing brush performance
Comment 2 jose americo gobbo 2017-05-17 18:09:17 UTC
Created attachment 352042 [details]
Performance Chart of Spacing Brush ranges - image
Comment 3 jose americo gobbo 2017-05-17 18:13:38 UTC
Created attachment 352043 [details]
two important brushes used in this test
Comment 4 jose americo gobbo 2017-05-21 14:14:41 UTC
Created attachment 352290 [details]
Add a Comparison with Acrylic 04 brush in the GIMP 2.8.22 (same conditions).

The performance on GIMP 2.8.22 of same brush and conditions (no dynamics, size, and spacing range) of the test made on GIMP 2.9, is more fast circa 4 or 5 times than the GIMP 2.9.
Comment 5 jose americo gobbo 2017-05-21 14:34:55 UTC
Created attachment 352295 [details]
Spreadsheet of my tests - spacing brush performance (GIMP 2.8.22 > 2.9)

Add a new test with comparison of Acrylic 04 tested in GIMP 2.8.22, with the same conditions of the tests made on GIMP 2.9.
Comment 6 jose americo gobbo 2017-06-01 19:53:09 UTC
Created attachment 353027 [details]
Comparison brush spacing performance between GIMP 2.8.22 and 2.9.5 (last git master)

The brushes used in this comparison are:
Acrylics 04
Texture Hose 03
In the same conditions related on the Description of this bug.
Comment 7 jose americo gobbo 2017-06-01 20:43:03 UTC
Created attachment 353033 [details]
Comparison brush spacing performance between GIMP 2.8.22 and 2.9.5 (last git master)

I have used two brushes that have different performances, Acrylics 04, a .gih, and Hardness 100%, a parametric.
On GIMP 2.9.5 both have a different performance.
On GIMP 2.8.22 both have practically the same performance, only with spacing 1 the Acrylics 04 decrease the performance.
Comment 8 jose americo gobbo 2017-06-07 17:43:00 UTC
Created attachment 353353 [details]
Spacing brush performance (vbr) with different image precisions

I have finished a test qualitative in the last GIMP git master (commit b7dd262).
I have used only vbr brush, 256 px h=1, in a document 6000x8000 px.
My machine has 4 processor and 8Gb memory - ubuntu gnome 14.04.3, Gnome 3.10.
A bit old my environment... ;-)
The 32f is more faster aways than 16f, in my tests.
The ideal mix for the performance is always have identical methods on Image precision and Paint Layer group.
The exception happens in 8i, but perhaps, it is a cause that is more faster the calculus for a 8i image than a 16-bit or 32-bit images.
Comment 9 jose americo gobbo 2018-04-04 00:52:10 UTC
This bug report is already in part discussed on bug 694917.

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