1 files changed, 94 insertions, 0 deletions
diff --git a/results/classifier/118/none/1618122 b/results/classifier/118/none/1618122
new file mode 100644
index 00000000..cf1370ae
--- /dev/null
+++ b/results/classifier/118/none/1618122
@@ -0,0 +1,94 @@
+graphic: 0.705
+peripherals: 0.609
+hypervisor: 0.579
+register: 0.577
+semantic: 0.556
+device: 0.547
+performance: 0.540
+PID: 0.532
+files: 0.527
+permissions: 0.510
+mistranslation: 0.508
+risc-v: 0.503
+ppc: 0.487
+debug: 0.486
+architecture: 0.486
+user-level: 0.471
+vnc: 0.464
+kernel: 0.453
+virtual: 0.452
+arm: 0.449
+socket: 0.438
+network: 0.427
+TCG: 0.407
+assembly: 0.374
+VMM: 0.372
+x86: 0.357
+KVM: 0.338
+i386: 0.311
+boot: 0.308
+
+qemu-monitor screendump very slow
+
+qemu-monitor screendump often using 10-20% cpu usage of one core to take a small capture.
+
+Most of the CPU usage seems to come from libpixman. There were many reports of libpixman becoming 8 times slower in newer releases.
+
+https://github.com/qemu/qemu/blob/0c56c6ab68902281094c7aac6305e2321c34c187/ui/console.c#L285
+
+
+Simple Valgrind Ir report.
+
+--------------------------------------------------------------------------------
+            Ir 
+--------------------------------------------------------------------------------
+56,592,286,124  PROGRAM TOTALS
+
+--------------------------------------------------------------------------------
+            Ir  file:function
+--------------------------------------------------------------------------------
+40,288,379,712  ???:0x000000000000caa0 [/usr/lib64/libpixman-1.so.0.34.0]
+ 3,585,795,168  ???:0x000000000006df20 [/usr/lib64/libpixman-1.so.0.34.0]
+ 1,763,982,432  ???:0x0000000000052360 [/usr/lib64/libpixman-1.so.0.34.0]
+ 1,517,832,033  ???:__memcpy_sse2_unaligned [/usr/lib64/libc-2.23.so]
+   993,997,885  ???:__GI_mempcpy [/usr/lib64/libc-2.23.so]
+   484,059,456  ???:0x0000000000050430 [/usr/lib64/libpixman-1.so.0.34.0]
+   460,109,168  ???:pixman_image_composite32 [/usr/lib64/libpixman-1.so.0.34.0]
+
+I tried taking a look on how to fix this, but it seems pixmap is deeply enrooted inside the monitor.  I wanted to try to simply take whats on the display and memcpy it into .ppm format manually creating the file header, but I cant figure out where the raw display buffer/image starts.
+
+For example this is DisplaySurface:
+
+struct DisplaySurface {
+    pixman_format_code_t format;
+    pixman_image_t *image;
+    uint8_t flags;
+#ifdef CONFIG_OPENGL
+    GLenum glformat;
+    GLenum gltype;
+    GLuint texture;
+#endif
+};
+
+Which as you can see already has the pixman_image_t. Maybe I should just work with that pixman_image_t?
+
+The most effective solution IMO seems to just memcpy from the display into a premade header for a .ppm or .bmp file assuming 24 or 32 bpp. No need for libpixman.
+
+Most of the CPU is coming from ppm_save(filename, surface, errp);
+
+graphic_hw_update(con) takes an insignificant amount. 
+
+The QEMU project is currently considering to move its bug tracking to
+another system. For this we need to know which bugs are still valid
+and which could be closed already. Thus we are setting older bugs to
+"Incomplete" now.
+
+If you still think this bug report here is valid, then please switch
+the state back to "New" within the next 60 days, otherwise this report
+will be marked as "Expired". Or please mark it as "Fix Released" if
+the problem has been solved with a newer version of QEMU already.
+
+Thank you and sorry for the inconvenience.
+
+[Expired for QEMU because there has been no activity for 60 days.]
+