How can I make colormap operate faster

3 visualizaciones (últimos 30 días)
Michael el 21 de En. de 2024
Comentada: Benjamin Kraus el 22 de En. de 2024
I have a plot of lots of square polygons, about 28,000 oif them. They are coloured using about 500 colours. I index the colours using a colormap so that I can change the palette of colours without redrawing the whole thing but it still takes about 4 seconds to change the colormap. It seems like it should just be rewriting a table in the graphics card so I don't know why it takes to long. My hunch is that what takes the time is the drawnow command which I need to use in order to see the change.
Is there any way to speed it up?
Maybe bypass a lot of the checks that drawnow does before showing the recoloured plot?
  2 comentarios
Matt J
Matt J el 21 de En. de 2024
Wouldn't it make more sense to plot this as an image? Your squares must be a few pixels in size at most.
Michael el 22 de En. de 2024
I might be able to get this to work but the squares are actually much higher resolution than the on screen image. See my answer to @Benjamin Kraus.

Iniciar sesión para comentar.

Respuesta aceptada

Benjamin Kraus
Benjamin Kraus el 22 de En. de 2024
Your guess about the behavior of the colormap command is incorrect. When you change the colormap, each individual rectangle is recalculated and resent to the graphics card.
I like @Matt J's suggestion to use an image instead, assuming that each square is fit together in a grid like pattern.
If the squares are not connected to one another (like an image) you are going to find substantially better performance if you use a single patch to draw all the rectangles.
For example:
% Coordinates for the lower-left of 1000 random squares.
n = 1000;
x = rand(1,n)*30;
y = rand(1,n)*30;
% Create the vertices for the four corners of 1000 1x1 squares.
xv = x + [0;0;1;1];
yv = y + [0;1;1;0];
v = [xv(:) yv(:)];
% Each "face" of the patch is a single square.
f = reshape(1:height(v),4,[])';
% Pick a random index for the color for each square.
c = randi(256,numel(x),1);
% Create a single patch to represent all the squares.
  6 comentarios
Michael el 22 de En. de 2024
That is the plot. The rectangles are not filled and because they need to have a precise line thickness I actually was drawing the circumference lines as filled patches. At the same time as I draw them on screen I output the polygons to an SVG file which I then convert to a high resolution PDF or SVG for printing. This is just one part of a larger image. I am using this to test the palettes and I am drawing the rectangles bigger than they will actually be because it takes so long to draw if they are too small.
@Benjamin Kraus, I took your advice and instead of drawing each patch I now add it to a big patch. Now switching the palette takes only 0.17 seconds, so thanks! The downside is that it take 3 minutes to draw instead of 25 seconds. But it's a good tradeoff.
BTW I preallocate 200,000 faces and 600,000 vertices and make the faces all NANs initially and change them as I add the new patches. This could be slowing things up in the drawing.stage. Is there a faster way
function addpatch(verts,faces,colour)
persistent bigpatch pverts pfaces pcolours lastvert lastface
if colour<0
% close the big patch cos we are finished
fprintf('Closing. Big patch has %d vertices and %d faces\n',lastvert,lastface);
pverts=[]; % free up some memory
if isempty(pverts) || ~isgraphics(bigpatch)
% initialise the big patch
% add the new verts/faces to the big patch
if lastvert>3*maxnFaces
warning('Max number of vertices exceeded')
if lastface>maxnFaces
warning('Max number of faces exceeded')
Benjamin Kraus
Benjamin Kraus el 22 de En. de 2024
@Michael, you said "Now switching the palette takes only 0.17 seconds, so thanks! The downside is that it take 3 minutes to draw instead of 25 seconds."
Can you clarify what you mean by "3 minutes to draw"? If it only takes 0.17 seconds to switch the colormap, then my guess is the 3 minutes is being spent generating the data to populate the patch. This should show-up in the profiler.
I can't run your reproduction code without data, but if you ran the MATLAB Profiler on your code it may identify what is taking the most time, and give you some places to look to optimize.
However, one thing that jumps out at me is it looks like you are creating the patch early, and then updating the data on the patch in each iteration of a loop (I assume your addpatch function is being called in a loop). I would suggest not creating the actual graphics Patch object until you are done collecting all the faces and vertices (and colors). I think that would be a relatively small tweak in your script: Just have your function return pverts, pfaces, and pcolours and then call patch once when the script is done.
I'm guessing here, but I suspect what is happening is that whatever process is calling addpatch is (directly or indirectly) trigging a graphics update (for example, calling drawnow or pause). This will allow you to see the resulting figure getting progressively updated every time you add new data, but it means the patch needs to be redrawn every time you add new data.
  • How frequently is your addpatch script being called?
  • Are you calling drawnow (if so, try replacing it with drawnow limitrate)?

Iniciar sesión para comentar.

Más respuestas (0)





Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!

Translated by