Line Chart: View with significant lag while configuring Node


I don’t quite understand what is happening but I believe to remember that in another post of mine I tried to explain my observation. First the screen cast where you will notice a significant UI lag when hovering the chart:

My former analysis in another post I couldn’t locate right now was, given the plenty resources my system has (AMD Ryzen 9 7950X, 64 GB RAM & 3080Ti GPU) that per Task Manager weren’t utilized that much, that rendering is happening on one of the CPU cores that is busy but not the GPU.

The Task Manager never marks Knime to leverage the GPU which is odd.

I suppose the new or any chart node for that matter is using the CPU which is widely known amongst web developers to hurt performance. Is there a way to test this hypothesis?

PS: Intriguingly, the interactive view isn’t that laggy.


Hey Mike,

It is not that unusual, that your browser makes use of the CPU rather than the GPU. There are some accelerations happening, but other than that most of the work is still done on the CPU. There are definitely implementations out there that use WebGL to leverage the GPU, but that is application dependant. For our views we rely on the echarts framework and their z-renderer engine. They have some WebGL examples which make use of your GPU, but these are mostly for 3D plots.
But rather than increasing the computing resources you usually try to minimize the rendering/computing effort. Even if you have lots of data in the line plot, you most likely get a similar good result when approximating the individual points, which echarts should already do.
My guess would also be that the rendering itself is not the problem, but that we put to much pressure onto the browser (keeping to much data in the browser memory). Which slows down the browser in general.
Are you able to share the workflow? I would be very interested in debugging this further on my system.


1 Like

Hi Daniel,

I can share it with you in a private manner. I will send it over to your email.

Upon preparing the workflow however, Knime faced a fatal error while generating the views.

hs_err_pid12956.log (149.0 KB)

knime.log (1.7 MB)

Some background processes were, even after Knime crashed, still running. Restarting Knime didn’t terminate them so I had to gently do it myself.

Once the workflow got prepped, I will send it to you including the confidential data to run in.

PS: Workflow and data is on its way to you. In order to replicate it you must kick off processing in the other components to put strain on the used cores.

That component is the one from the screenshots in my initial post.


PS: Happened again in that workflow but with another Line Plot Chart that didn’t had any issues before. The table only has 120 rows with 13 columns.

240711 Chart visualization not rendeering threaddump-1720680254976.tdump.txt (62.7 KB)

Neither can the node be configured nor does it render anything.

None of the chart nodes are configurable. I wonder if upgrading from 5.2 to 5.3 caused a regression we could not test.

Checking the interactive view it becomes more obvious that there is a regression :confused:

Definately a regression as even the JS-based nodes fail to render.

Hey Mike,

just to keep track of the issues, let me try to summarise the problems:

  1. KNIME crashed when generating lots of heavy views
    Tried to reproduce but currently no “luck”. It is the first time I heard the fan of my MacBook, but other than that all works as expected. I will try to find me a windows laptop and try again. Maybe windows is less graceful under pressure.
  2. Processes were still alive after the crash
    Will investigate once I can reproduce the crash
  3. Views not showing up
    This is very likely the problem we currently have in 5.3?

Greetings and thanks,