GNOME Bugzilla – Bug 663582
Brush outline is too slow
Last modified: 2018-05-02 04:33:34 UTC
Fast drawing a line, brush outline stays far behind the brush. It is unacceptable when you drawing on the graphic tablet.
What sort of brush(size, type, etc.) and what you consider fast? Please describe the usage when it does not perform for you. Compared to 2.6 the 2.7.3 has considerably improved outline performance and performance difference with outline on and outline off is no longer outrageous... however, as always there is room for improvement. There may be cases when things like display driver in use can cause outline drawing to perform badly as well.
I think it does not depend from brush. At least I did not notice. I compare the rate of about 2.6 taking it as a basis. If you look at this video frame by frame you will see the difference: in version 2.7 contour brush is not updated every frame, in contrast from 2.6 http://dl.dropbox.com/u/43039840/gimp-brush-test/gimp-2.6.11-brush-test.ogv http://dl.dropbox.com/u/43039840/gimp-brush-test/gimp-2.7.4-brush-test.ogv http://dl.dropbox.com/u/43039840/gimp-brush-test/gimp-2.7.4-brush-test2.ogv From a practical view, perhaps there is no difference but when you draw an unpleasant sensation arises.
Part of this is actually intentional. It was a trade off between actual painting and updating the outline. In 2.6 very expensive outline drawing made the actual drawing considerably slower. Large brushes suffered most. In 2.7 the outline is updated whenever there is time left over from the actual painting. It should disappear tho, when it falls to far behind, but that simply hasn't been implemented yet.
Do you mean a mode when brush outline is displayed when there is not pressure on the pen?
no, a hybrid mode that hides the outline when it gets burdensome to the process... but that would be near impossible to implement with the current architecture, so the suggestion I had today was to make the outline display dependent on brush velocity and force it to update at specific rate when visble, costing a little bit of the actual painting performance.
Then I think it makes sense to introduce yet another mode to display contour brush - it displayed only when you change the brush size. When change brush size is important to see the result.
Hi Alexia, I used Gimp ( gimp-painter 2.6 series ) intensively to paint daily on a regular basis, between 2008 and 2011. With the update to 2.8 back in the start of the year 2012 , I had to drop usage of it. Why dropped my main tool ? because I hadn't choice ; I couldn't paint on it anymore and my old Gimp-painter version woudn't install on recent Ubuntu. On Gimp 2.8, I have problem with the 'laggy' outline feeling. Same happen to other Gimp digital painter I know. And we keep discussing about this mini trauma in our FLOSS user life. Tonight while broswing to try to find more info about, I found the actual bug report and the videos of KEIII : they are totally representative of my main problem. Detailing the issue : Here I don't use 'cursor'+'outline' as proposed in the Gimp default . I use the 'outline only' option when I paint. ( Video ex: http://youtu.be/NUUUiMe_SIE?hd=1 ) The 'outliner' represent the tip of my brush and my cursor , and if it teleport across the canvas all the time and blink, I have no feedback about the direction of my stroke. It make me loose control. It's really uncomfortable to paint like this. This and the new fat "dashed brush outline" decoration really are change I would like to see reverted to the 2.6 way or improved into a new way. I hope you'll consider my request. Thanks in advance for your time.
Is the difference in the OGG videos from comment 2 really that bad? It doesn't look that bad to me, but I'm not a painter. We *could* perhaps enforce updating of the outline at the current cursor position, at the cost of rendering performance. We'll have to look into this. Also, this bug is about 2.7.x, didn't this improve with 2.8?
@Michael : Sure the video from KEIII could show a larger difference. I speedly recorded a video to show it better : http://www.davidrevoy.com/XYZ/gimp-28-brush-lag-demo.avi Thanks for your interrest into it. I'm around for other questions/demo in case. ( I use 2.8.1 via PPA, Kubuntu 12.04 ; I tested this also on XFCE, Gnome desktop )
Created attachment 225802 [details] [review] Draw tool stuff with at least 20 fps I hacked up a patch that, in addition to delaying drawing by a timeout in order to avoid performance killing drawing for each tablet motion, ensures a minimum frame rate of around 20 fps. Alexia, David, please try this patch. I'm not a tablet painter and can't really judge if it makes actual painting more laggy instead.
Hi, I patched today's git master with the patch. And result here is about 10 time slower, with outliner almost freezing in place. A bug ?
Git master is not fit for many reasons... most of them to do with gegl migration. I patched 2.8 with it and I think the cost is worth the improved interaction. It still lags a little bit on large brushes and a3 canvas but when you slow down it catches up fast.
But since you get such dramatic negative results, David, you should perhaps try 2.8 too.
Thanks for the information. Sorry, I didn't knew the patch was made for 2.8 . Thanks for pointing the way to make it work. I want to patch 2.8 source with it. But I don't know something about how to do this. Should I find in the Git commit the commit where Gimp 2.8 get, or the switch a special made branch ? Should I have to build Babl and Gegl too to an older date ? Thanks for your response, and sorry for this technical 'out of topic' part of the discution.
you can just check out 2.8 like this: #this removes uncommited changes git reset --hard master #this checks out the 2.8 branch git checkout -b gimp-2.8 origin/gimp-2.8 #apply the patch git apply <patch file> And then autogen and build as usual. You don't need older babl or gegl. When you want to go back to master just do git checkout master and back to 2.8 git checkout gimp-2.8 If you want updates in that branch from the repository git reset --hard origin/gimp-2.8
The patch works for both, but 2.9 and it's gegl backend don't yet perform at all, patch or no patch for painting. There's work made in gegl to improve that tho.
Thanks David for pointing out the severity of this issue, I totally forgot it over all the master hacking. Fixed in master and gimp-2-8: commit b03591e4055ccf32631069cf95067a09bf698e42 Author: Michael Natterer <mitch@gimp.org> Date: Thu Oct 4 20:42:13 2012 +0200 Bug 663582 - Brush outline is too slow Keep around the last drawing time in GimpDrawTool and make sure we draw at least with a frame rate of around 20 fps, which feels reasonably non-laggy. (cherry picked from commit fd4e220c28d42a3b0169df21dc803f5601a6691e) app/tools/gimpdrawtool.c | 20 +++++++++++++++++--- app/tools/gimpdrawtool.h | 11 ++++++----- 2 files changed, 23 insertions(+), 8 deletions(-)
@Alexia : I get an error when trying to change to gimp 2.8 : "$ git checkout -b gimp-2.8 origin/gimp-2.8 fatal: git checkout: updating paths is incompatible with switching branches. Did you intend to checkout 'origin/gimp-2.8' which can not be resolved as commit?" I tried to download the source of 2.8.2 from the official website, but this version refused the autogen step. As I'm only a user, I have no idea what to do else. So, as I read the page here : http://git.gnome.org/browse/gimp/log/ and so understood the patch of Michael get commited in master ( the precedent bugtracker message also show it ) . So, I deleted my source folder, and redid a clean build ( assuring that when typing 'git log' I see the last commit ). But I still have the 10 time slower issue in master. ( even running with a default ~/.gimp2.9 pref folder )
Better use "git checkout -t remotes/origin/gimp-2-8" which creates a local gimp-2-8 branch that tracks the upstream branch. As Alexia said, master is broken for other reasons, don't try to paint there, it's hell :)
@Michael : Thank you. The command to switch branch worked for me. I had to clean GEGL and BABL from my previous 2.9 install for this prefix ; then re-clean, re autogen and build. After new test I didn't see improvements, my brush outliner still freeze here and there giving me no feedback about 'where i'm going'. Sorry, I hope it's not local to my computer ( I tryed reseting my ~/.gimp2-8 folder as well , and to exclude an eventual KDE bad interraction I rebooted under a XFCE session too to make test ) I have in About dialog Gimp 2.8.3 , so I guess I correctly test the right version. ( I didn't applied the patch , because, as far as I understood and read with 'gitk' app in the git log, the patch was commited ) The most common freezing position is at the first dab x & y position on the canvas (the origin of the strokes ). Then , the outliner 'jump' in most of case to the end position , on stylus release. If the brush get a bit medium to big ; it can freeze longer.
That is odd. When it freezes like that, does the painted stroke freeze too, or does just the outline stay behind?
no, the painting strokes continue to display on canvas , only the 'brush dashed outliner' freeze into position. But the painting stroke can have a delay with mid or big brush/preset. So, it's make hard to paint at the desired emplacement.
Sorry for asking the silly question, but do you really use the newly built gimp? It should draw the outline at around 20 fps now, and when it flushes the paint stroke to screen, the outline would be drawn too. Alexia, can you look at that code too please?
@Michael : No problem for the question. Yes I use the built version. I can confirm because the built version got in About dialog the number '2.8.3'. And other version installed from PPA on my system display '2.8.2'. I can make screenrecord to show, or sharescreen in G+ hangout , if needed to see it interactively.
Apparently my laptop is too fast and the improvement does not exactly help much on many machines since the drawing of an outline still happens when there is time left over from the stroke in an idle handler. So I made a patch that does not do this, but instead simply limits the draw rate of the outline. this was not an option for the xor drawing, because it broke horridly but it works fine now with cairo. so at a limited cost of painting, the outline sticks to the end of the painting. At 20fps its higher than Id like it to be, but apparently people find preferring the actual stroke to be disturbing...
Created attachment 225897 [details] [review] Patch for rate limiting instead of idle handler draw.
@Alexia : I applied your patch and rebuild on 2.8.3 Git , and I still have the issue. My computer is a icore7, 8 core 2.93GHz with 8GB of Ram and good CG card. So, I don't guess about an hardware problem. To reproduce the issue very noticable ; just load a brush from GPS brush set ( having a bitmap brushmask + opacity on the pressure ) ; a canvas of 3000x2000 is suffisent. Exemple in detail : Oil Brush ; default size , 72 ; canvas of 3000x2000 at 33,33% viewport. Here I have a freeze on start and finish of the outliner. On other brush with ie, a larger spacing it looks ok. But the movement of the outliner feels shaky and not following really gesture of the user.
Instead, let's try using the right interval for 20 ftp, sigh... commit 8d6634c8eb485764f0d88be80e164adbed473096 Author: Michael Natterer <mitch@gimp.org> Date: Sat Oct 6 00:03:47 2012 +0200 Bug 663582 - Brush outline is too slow Don't confuse microseconds with milliseconds: the 20 fps interval is 50000, not 50, sigh. (cherry picked from commit db5c952c4e01f3055e6f77a0315be42f52382501) app/tools/gimpdrawtool.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
Additionally, I am stupid and Alexia is completely right, the drawing still happens in the timeout. Will merge the stuff to hopefully really work...
So, please try this, should be really fixed now, I think :) commit 55792c2f30fac01940d0a37990483f0f2d66bce5 Author: Michael Natterer <mitch@gimp.org> Date: Sat Oct 6 00:27:49 2012 +0200 Bug 663582 - Brush outline is too slow One more try: merge the spirit of Alexia's patch, but don't disable the timeout, only make sure the minimum fps is also applied when drawing is triggered by gimp_draw_tool_resume(). (cherry picked from commit 4218d9342f68de4fedec166df0a64585dc64081a) app/tools/gimpdrawtool.c | 23 +++++++++++++++-------- 1 file changed, 15 insertions(+), 8 deletions(-)
David, if you tired my patch right there's no way you could have the issue of outline detaching from the stroke head. Maybe you had a previous binary running from a previous build and didnt notice or didnt run the right binary? I sure stepped on that rake a few times testing it. However, the whole stroke will detach from your mouse pointer as before in 2.6 because the actual stroke is now again slowed by the outline... That's the tradeoff. Having many cores does not help much because gimp cant leverage multiple cores for this. If you monitor performance you'll see that one core is maxed out when you paint.
@Alexia : Ok. I'm almost sure I do mistakes as you probably are. I trust you said you solved/patched it with a revelant result I can't see. Even if I'm noob with prefix and compiling sorcery ( ^ u ^ ) , I do my best to always do thing clean. I paste here my method to apply patch, say me if I do mistakes : ( sorry if it sounds noob method , I learn from googling here and there and various tutorials mixed, so my 'method' is certainly a key to the problem ) #cleaning sudo rm -R /opt/gimp-dev sudo rm /usr/bin/gimp-dev #export/prefix export PATH=/opt/gimp-dev/bin:$PATH export PKG_CONFIG_PATH=/opt/gimp-dev/lib/pkgconfig export LD_LIBRARY_PATH=/opt/gimp-dev/lib #building cd ~/sources/gimp-dev/gimp/ git reset --hard git pull cp ~/Downloads/0001-app-use-rate-limiter-at-5000msec-instead-of-idle-dra.patch ~/sources/gimp-dev/gimp/0001-app-use-rate-limiter-at-5000msec-instead-of-idle-dra.patch patch -p1 < 0001-app-use-rate-limiter-at-5000msec-instead-of-idle-dra.patch ./autogen.sh --prefix=/opt/gimp-dev --disable-gtk-doc make -j8 && sudo make install -j8 #linking and launching sudo ln /opt/gimp-dev/bin/gimp-2.8 /usr/bin/gimp-dev gimp-dev --- Thanks for your lovely patience and care with me to both you and Michael. Thanks. I will re-apply this method, update GIT, and apply again your patch Alexia, and re-test.
Don't apply any patch, it will conflict and is not needed any longer. Vanilla git *should* work. "should"... let's hope this time.
Ok, I tested Vanilla git, and the behavior is worst. Now, when crosshatching with small brush , or tracing with large ; the outliner + the strokes freeze at the origin visually, then outliner jump to the final position and strokes appear. I have made a video to give you feedback : http://www.davidrevoy.com/XYZ/gimp-283-irresponsive-large-strokes.avi In my opinion; -I know it's probably not possible to do with patch - but for painting the 'right' behavior is more near to this : http://wstaw.org/m/2012/10/06/gimp-stroke-ora.jpg ( or video here : http://www.davidrevoy.com/XYZ/2012-10-04_krita-perf-feedback.avi not made for purpose, but who show in Krita how the outliner movement are not affected by computation of the stroke ) I also know ( very well ) older Gimp 2.6 didn't worked like that. It has issue too with large brush, outliner+strokes where "slowing down" screwing the path or forcing the user to trace very slowly ; and you couldn't initiate a new strokes if the previous one wasn't finish. But it was still feel more 'right' than the 2.8 behavior. One workaround could be to transform the outliner to a small and discrete 3x3 pixel cross ( or whatever discrete cursor ) during the 'lag time' to let user have feedback about the path he is drawing. It would work
Hmm, did you update from git? How large is your brush?
Ah didn't see the video, that indeed looks like total crap :( It might be the shape of the outline that makes it so bad. Perhaps we should simply use an ellipse or the brushes dimension's, at least *while* stroking.
Maybe you can play with the following define a bit and tell us what amount of microseconds gives a good result, if any: #define MINIMUM_DRAW_INTERVAL 50000 /* 50000 microseconds == 20 fps */ it's in app/tools/gimpdrawtool.c at the top.
Mitch, I like the idea of swapping an outline for a small cross when it starts to lag instead of idle drawing and just keeping the rate limiter. How to go about doing it im not so sure...
@Alexia : Yes, the default preference in a fresh Gimp install , with outline + cursor when a paint tool is activated ( arrow + icon on corner of the tool used ; Preference > Image Windows > Show pointer for paint tools ) works for me well about the movement feedbacks ; I no longer focus on the outline flickering. The outline keeps a great feedback for size, appearance, etc... The main problem of actual cursor ( and thats why I remove it ) is the obtrusive 'appearance' of big plain black triangle 45° angled + brush icon on the corner. Just to give idea , from other software I knew by the past ; Corel Painter 9.5 had this same way to handle outlines + cursor as Gimp does , if I remember well. Here how they 'solved' the cursor appearance ; via the preference panel : http://apps.corel.com/painterix/training/tutorials/tip_drawing_cursor_01.gif ; in fact they don't solve really the thing ; they just propose many cursor to the user to simulate his 'digital pencil tip' . Witch is fine in a way ; I saw many Youtube video timelapse of Painter user ; and they often use different. So a matter of taste probably here ... The 'orientation option' is a bit fancy , but I imagine left-handed artist can appreciate the way to make the brush orienting as a left-handed. For my own taste , a tiny cross at the center of the outline would certainly solve it. It can be displayed all the time to indicate the center of the brush outline too. It just have to be tiny and smooth as the 'cursor'.
Another small improvement, shouldn't make much difference. I can now paint fluently on the tablet with a few hundred pixel brush on a 3000x2000 layer. I verified that the current code skips almost *all* drawing completely. David, can you try again please, make sure you did "git pull" in your gimp-2-8 branch and after make, run the uninstalled binary app/gimp-2.8 to be 100% sure. commit cd6fa1d9c90daa8297ad8dc548328bb337e9dd3c Author: Michael Natterer <mitch@gimp.org> Date: Sat Oct 6 16:39:14 2012 +0200 Bug 663582 - Brush outline is too slow Even less drawing: let the timeout running if it triggers within the 50ms since the last drawing, so it's reduced to its actual purpose of updating to the actual cursor position after framerate-limiter skipped drawing. (cherry picked from commit 52d933a1cc08ba388c63c58baa95f26c059df9b0) app/tools/gimpdrawtool.c | 6 ++++++ 1 file changed, 6 insertions(+)
I should add, I can paint fluently on *master*, unless other unrelated bugs happen and make it block for no apparent reason (it catches up tho).
I tested and I see the difference. Thanks Michael for your work, and for the good advice to perform test. With the actual change, the outliner works now as it was in 2.6 ( with a big of more flickering ). The outliner follow the last dab computed on the canvas, but is still behind the user real location. Thats the "slowing down" effect I describe on comment 36. This is still better than before in regards of user feedback. But not for the performances at the same time. I'm interrested in testing maybe the original + a discrete little cursor over. Maybe it can mix the fluidity and smoothness of moves of the cursor. And the performance of an outliner who can disapear/teleport if ressources are missed.
That's great news! :) In the current state, I don't think we can improve the "slowing down" much via outline drawing, we're hitting general brush size and machine speed limits now. It *does* take some effort to draw complex outlines tho, so I'm leaving this bug open. Let's try with this state before we add small crosshair, or brush-sized ellipses.
I forgot, you can easily test if outline drawing is a performance factor on your machine by disabling it in prefs. If performance stays about the same, we're done with this bug.
@Michael : On very , but I mean very good news, is a side effect. I was experiencing a lot of lag on also all the 'on-canvas' new 'bold' widget user feedbacks. ( text / selection / etc... ) I don't know how it can be related, but they just became smooth again, and I feel very happy about. Exemple video ( 5MB ) to show what I'm talking about : http://www.davidrevoy.com/XYZ/gimp-selection-on-canvas-improvement-performance.avi ; ( on video, a before/after : launched Gimp 2.8.2 from ppa , after launched newly built 2.8.3 )
Wow! Yes that's indeed the same fix, especially when you use a tablet which generates *lots* of events. Cool :)
I already had one feedback of a user who compile it of speed increasing on my blog. So, I guess I'm not alone to already feel the change ^ ^ I guess my tablet produce a lot of input ( Intuos4 Medium ) as well as my mouse ( a gaming mouse 4800dpi ). Another feedback I have about this outliner discution is about the new minified icon Gimp use when outliner is too little. I understand Gimp after 2.7 couldn't have the outline/selection/on-canvas helper rendering in sort of 'negative' blending mode as in Gimp 2.6 ( ex ; on 2.6 , even if the outline/selection/on-canvas tools where 1px fine, they where bright on dark background, and dark on bright background ). Now, as far as I understood, developers are constrained to adopt 'fat' line, and put 75% opacity black and 75% opacity white in the outline/selection/on-canvas tools. A clear regression was for the outliner when reduced to minimal ; it takes the shape of a cross witch is really not user friendly to draw thin lines or make line-art (ex : black outline on manga characters ). Mypaint have the same limitation of using a cursor black&white ; and their minimal cursor proven to work for drawing and painting thin line ( after discutions, bug report about ). Here is a picture with Gimp 2.8 cross , and a rounded b&w outliner 'a la' Mypaint : http://wstaw.org/m/2012/10/07/2012-10-07_gimp-minimum-outliner.png ( light grey represent white 75% , and dark grey represent black 75% ) So, just a low-hanging fruit I guess to make Gimp more confortable. Sorry if it's a bit out of topic.
I must admit I haven't seen that fallback crosshair cursor in a while, also, via prefs it's possible to configure the paint tools to have neither brush outline nor cursor, which is pretty broken. I think we need a complete plan for redoing that in master.
*** Bug 683726 has been marked as a duplicate of this bug. ***
*** Bug 699370 has been marked as a duplicate of this bug. ***
I just refactored the brush outline/fallback drawing and it seems the only thing to finally close this bug is to get rid of the "cross" fallback, or was there anything else missing?
Whatever, these commits should fix the remaining visual glitches in master, please reopen if there is anyhting left to do: commit d897188e328fc8af86124282aea81e304c7b699c Author: Michael Natterer <mitch@gimp.org> Date: Sat Apr 12 15:03:15 2014 +0200 app: also move the "draw brush outline" logic from brush to paint tool So all paint tools honor the setting. Add GimpPaintTool::get_outline() which either returns an outline, or calls gimp_paint_tool_set_draw_cursor() and implement it in GimpBrushTool and GimpInkTool. Handle all brush/circle/fallback drawing in gimp_paint_tool_draw(). app/config/gimprc-blurbs.h | 2 +- app/tools/gimpbrushtool.c | 168 +++++++++++++++++------------------------------------------------------- app/tools/gimpbrushtool.h | 4 -- app/tools/gimpinktool.c | 21 +++++---- app/tools/gimppainttool.c | 64 +++++++++++++++++++++++++--- app/tools/gimppainttool.h | 6 +++ 6 files changed, 117 insertions(+), 148 deletions(-) commit 6d5b6a648d0b50752b13ff38e88655aea8e2ca36 Author: Michael Natterer <mitch@gimp.org> Date: Sat Apr 12 22:17:55 2014 +0200 app: turn the paint tool fallback cursor cross into a circle app/tools/gimppainttool.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
I apologize for bringing this bug up again two years later, but has the fix been patched into 2.8.18? I'm running the latest release on Windows 10 (x64) and it looks like it's still happening.
No, because it's a too intrusive change for 2.8, not just a simple bug fix :/
Just tried out the latest GIMP 2.9.6 (commit 5afea2f) snapshot for Windows and I'm sad to say the bug is still present. Was the bug intended to be fixed by 2.9 or for a later version?
This problem is still present in 2.10.0 RC. Brush outline is really useful, but the lag/delay when you paint is very annoying, it really makes you lose concentration. It would be really nice if some kind dev finds time to solve this problem. Thank you very much.
By the way, if you also have visible crosshair pointer and for example you use a circle brush, when you paint then the crosshair and circle brush outline never remain aligned, which makes this quite distracting as well. They remain aligned only when you move the pointer over canvas without painting. But when you start painting, it loses concentricity and they stop being aligned.
What version exactly is this?
Mmm, if you ask then I guess the problem is not reprodcible in all cases. Sorry for supposing the opposite and not giving information of the system. I currently use GIMP 2.10.0 RC2 on Kubuntu 18.04 from this PPA: https://launchpad.net/~otto-kesselgulasch/+archive/ubuntu/gimp-edge Here how does it behave: https://media.giphy.com/media/8YNxgiGcQ0Ccw7w868/giphy.gif You will notice that crosshair and brush outline remain aligned only when you remain still on unpainted canvas.
*only when you remain still on unpainted canvas. I mean: "only when you remain still over canvas without painting".
Ah that lag. I don't find that disturbing at all, and I don't think we can completely avoid it.
Come on Michael, when you paint you should pay attention only in your work, not in strange/weird things that happen with pointers. It is distracting. But if this is difficult to solve, there is no problem. Thank you anyway. I think that I'm going to use brush outline only. When you have brush outline enabled and you use very small brush size, a different crosshair automatically appears and that different crosshair works fine most of the time. If the size of the brush is very small between 1 and 2 (maybe between 1 and 3 with some brushes), that crosshair does not work correctly (does not appear or blinks some times). It would be good to at least that different crosshair work well in small sizes of brushes.
Just to be clear: do you mean the outline lag while you are painting or while you are just hovering the canvas?
I think both. Excessive lag when you do not paint is distracting. And when you paint in addition to the small lag, the fact that crosshair and brush outline do not remain aligned with almost independent movement each, is also distracting. But as I said, I could disable crosshair and use brush outline only. The problem here is when you use small brush size, pointer is not visible or very difficult to see. The automatic crosshair that appears in small brushes could be a solution, but it is not working properly either, crosshair does not appear, or it is blinking/flickering Is this a known problem? https://media.giphy.com/media/1BH8Ig3hmm9XPqJ2d0/giphy.gif
Michael, I have to make a clarification because part of the problem is because of my mistake. Having crosshair and brush outline at the same time, when I was referring about brush outline and crosshair never remain aligned while you paint, it's because I had Smooth Stroke enabled. So sorry for that.
Running GIMP 2.10.0 stable now on Windows 10 x64 and the brush outline is still laggy and choppy. I've uploaded a clip on gfycat as an example: https://gfycat.com/QuerulousAncientAmericanwigeon Thankfully OBS glitched out and shows a corrupted square where the system cursor would be if not hidden while using the brush outline. It's pretty visible on how behind it is and it throws me off when trying to paint something since version 2.8.