Adding more than 6 images (4602 x 2384) to PCB slows down screen drawing considerably.
Is there some GPU memory limitation that possibly causes a fallback to software rendering?
GPU: Intel Xe i7 11th gen
Application: KiCad PCB Editor x64 on x64
Version: 7.99.0-3134-gf47cc39208, release build
4602 x 2384 what? apples? oranges? cm?
Each image has 4602 x 2384 colorful pixels
Thanks, I won’t ask why six. 
Someone may reply now, knowing the size of the images… my bed time.
Why ? you could simply scale down your images to something that is more representative of what you will get on the PCB, I find it hard to believe you actually need 10mpixel images.
My UltraHD TV (which I use as a monitor) has (very) roughly that many pixels. It’s more than 1 m wide and I have to go about as close as 30 cm to see the pixels. I really can’t imagine why someone would need 2 x 3 row of these images for a PCB. Or are they used as layers? In any case most manufacturers wouldn’t even do so large a board where this large image would give any benefit for the layout design.
Until PCB is not to be one of pages of family photo album (6 images per page) 
At 800ppi, a 0.25mm bga pad comes out as 8 pixels wide.
Anyway, I was just wondering if there was a flag or something to bump the memory limit or if it is my internal GPU.
The question is still:
Why do you want to add mega-images to a PCB?
No. I think the feature just wasn’t coded with very large images in mind.
That is about 200MB of uncompressed pixel data. A bit much, but when I look at your screenshot, I guess it’s a reverse-engineering job of a relatively big multi layer PCB, and the resolution does not seem excessive.
Maybe the video card is the bottleneck. Maybe there is some buffering problem. I am already quite happy that it is even possible to load background images for reverse engineering. I am guessing there has never been much performance testing done on this feature.
I think the image overlay and linking them to layers is pretty workable for simple RE. It’s a nice feature. For me, it’s just for visual inspection at this point.
The big images also add 20MB of the compressed image to the PCB file which is slightly annoying for revision control. So I actually created a separate PCB file with the images and copy/paste them back if needed.
Thanks for the clarifications
Is this commit by any chance related to this topic:
What does “considerably” mean?
And in which circumstances does it manifest itself? Is it only during panning / zooming, or also with other operations?
I assume these pictures are for different PCB layers, and probably scaled too. I also assume that most of the time 5 of the 6 pictures are turned off. Does it impact performance even if the image is invisible? KiCad implements transparency for images and it is possible for example that invisible 60Mega pixels are being rendered with 0% opacity for each pan / zoom operation. Things like that are easy to fix, but as long as the pictures are small enough, nobody bumps into a performance problem and such bugs are not fixed.
I don’t know much about graphics programming, but I can imagine that the (unscaled) pictures are loaded once into the video card memory buffer and the video card does all the processing. And if the pictures do not fit in the video memory, then they have to be transferred from the main memory to the video card each time. If that is the case, a (gaming) video card with 4GB memory costs around EUR100.
Normally I had like 60fps with no pictures. And maybe 50fps with 6 big pictures.
Above that, panning / zooming became like 2fps, which resembled “Fallback graphics”, but it may not be!
If I turned on “Fallback graphics”, it was unusable even with one picture (~4fps). 1-2fps with >1 pictures. 10fps with no pictures.
Each picture is on a different layer, but it doesn’t seem to make a difference. Scaling is 1.00. Pictures are half transparent.
Hiding images solves the fps issue.
When images are shown GPU ram increases 0.3GB, but there is still memory left according to task manager:
I tried today’s nightly. That commit fixes the issue.
I stress-tested it with 14 big pictures and it is still usable with my integrated gpu. FPS drops maybe to 30fps when panning, but it’s all usable.
Very cool.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
