On the Workbench Canvas Performance

Some people might have noticed that Workbench runs very slowly and flickers a lot in their machines. Other people will be able to work without noticing any significant sluggishness with the diagram graphics. The difference is because Workbench’s custom canvas may use hardware accelerated OpenGL graphics or non-accelerated software rendering, depending on the system (ie, whether or not a 3D accelerated graphics card is available or not). We were expecting that the most reasonably recent machines (maybe 5 years old or less) would have at least some basic graphics acceleration, but for some reason, that seems to not always be the case. Apparently, some people that have decent systems with ATI or Intel cards seem to get the fallback software rendered canvas, which will result in sluggish graphics.

We are still not sure why Cairo/Glitz (the underlying graphics library used by our drawing canvas) is not working as intended for everyone, but we are working on getting this performance problem solved in at least two fronts:

  • one is to add support for the Windows GDI backend of Cairo, which seems to be faster than the software based OpenGL rendering provided by Mesa. We already use that for Windows printing, so we get that for almost free;
  • another thing that’s being worked on is general drawing optimization, so that the number of redundant drawing operations is minimized. Those changes should make Workbench work much faster and smoother for everyone, as we intended to have from the beginning.

So expect future versions to have an improved canvas and Workbench will be much faster when you work on larger models.

9 thoughts on “On the Workbench Canvas Performance”

  1. Great news!
    thank you do much for working on this.
    Would this optimization also be available for the Linux version?

  2. I was wondering what was going on with the canvas, as it didn’t matter if I ran Workbench in Software or Hardware modes. Thanks for the update. Looking forward to the Linux version so that I can use it at work 🙂
    I’ve also had issues with elements disappearing. They’re there but invisible until selected. Is that related to the same issue described here?

  3. This looks like more than just a hardware vs software pipeline issue. Software renderers haven’t been this bad for decades. The software pipe appears to know how to do only one thing — redraw the entire screen. There’s no window system out there that won’t give you a clip list of areas to be redrawn so that you don’t have to redraw the whole thing. Most will use saveunders so you don’t have to draw at all for drop down menus. Heck, it even redraws the entire window every time the mouse enters or leaves.

    Is there a way to force the use of the hardware pipe? What exactly are you looking for to determine whether the graphics is “capable” enough? I’m using on-board nVidia graphics, but it’s been fine for a lot of basic 3D stuff in the past (and I note that Cairo is a *2*D graphics library, not 3D).

  4. We’re already doing selective redrawing in the new GDI code.
    There doesn’t seem to be the concept of save-unders/backing store
    in Windows forms, at least I couldn’t find anything like that (I’m a
    Linux guy so maybe I’m missing something). As for spurious redraws
    that’s something unrelated to the hw/sw render issue and is being
    addressed as well. It just takes time.

    As for forcing OpenGL use, I don’t know exactly what’s the problem.
    It seems to be a driver version issue since Glitz requires a certain OpenGL version to work.
    I’ve added some diagnostic info so that ppl can tell us the version
    of their driver and whether hw rendering got properly initialized or
    not.

  5. I am having this performance problem on a Toshiba Qosmio G25-AV513 with a Geforce go 6600 VPU. I originally had the Toshiba Nvidia driver 7.1.1.8 dated: 1/13/2005 and had the problem, updated to the 7.8.8.2 dated: 8/23/2005 driver from Toshia and still had the problem and finally went to laptopvideo2go and got the 6.14.11.7815 driver dated 9/22/2008 but unfortunately the problem still persists 🙁

  6. Another thing I have noticed, due to the sluggishness of the display, when dragging and dropping an object on the workbench canvas the mouse release event uses the ‘current’ mouse XY as the repositioning point for the object as opposed to the mouse XY position at the point of releasing the mouse button.

    Due to the canvas rendering speed the glitch is more pronounced as I have often times moved onto the next object to move by the time the canvas catches up which ends up moving the previous object to the current mouse XY position. Does this make sense?

  7. Here’s my system ‘System Info’ from Workbench…

    Looking for user plugins in C:\Documents and Settings\dbennett\Application Data\MySQL\Workbench\modules
    Looking for user plugins in C:\Documents and Settings\dbennett\Application Data\MySQL\Workbench\plugins
    MySQL Workbench SE for Windows version 5.0.30
    Cairo Version: 1.5.12
    Rendering Mode: GDI Rendering
    OpenGL Driver Version: Not Detected
    OS: Windows XP
    CPU: Intel(R) Pentium(R) M processor 2.00GHz, 2.0 GB RAM
    Video adapter info:
    Adapter type: NVIDIA GeForce Go 6600
    Chip Type: GeForce Go 6600
    BIOS String: Version 5.43.02.49.D1
    Video Memory: 131072 KB

  8. dbennet: Does the sluggishness happen right from when the app is started? Or does it start getting slow the longer you use?

    If the canvas is slow from the beginning, would you consider making a small screen capture video where you can demonstrate the slowness?

    Thanks,
    Alfredo

Leave a Reply

Your email address will not be published. Required fields are marked *

Time limit is exhausted. Please reload CAPTCHA.