Everything else works fine for my pc... at least that it looks like.
Are you using the proprietary nVidia driver???
Yes I am running on proprietary drivers 8762
part of my /var/log/Xorg.0.log
sque@ubuntu:~$ cat /var/log/Xorg.0.log | grep NVIDIA
(**) | |-->Device "NVIDIA Corporation NV36 [GeForce FX 5700]"
(II) Module glx: vendor="NVIDIA Corporation"
(II) Module nvidia: vendor="NVIDIA Corporation"
(II) NVIDIA X Driver 1.0-8762 Mon May 15 13:09:21 PDT 2006
(II) NVIDIA Unified Driver for all Supported NVIDIA GPUs
(--) Chipset NVIDIA GPU found
(**) NVIDIA(0): Depth 24, (--) framebuffer bpp 32
(==) NVIDIA(0): RGB weight 888
(==) NVIDIA(0): Default visual is TrueColor
(==) NVIDIA(0): Using gamma correction (1.0, 1.0, 1.0)
(**) NVIDIA(0): Option "RenderAccel" "true"
(**) NVIDIA(0): Enabling RENDER acceleration
(II) NVIDIA(0): NVIDIA GPU GeForce FX 5700 at PCI:1:0:0
(--) NVIDIA(0): VideoRAM: 131072 kBytes
(--) NVIDIA(0): VideoBIOS: 04.36.20.19.06
(II) NVIDIA(0): Detected AGP rate: 8X
(--) NVIDIA(0): Interlaced video modes are supported on this GPU
(--) NVIDIA(0): Connected display device(s) on GeForce FX 5700 at PCI:1:0:0:
(--) NVIDIA(0): Samsung SyncMaster (CRT-1)
(--) NVIDIA(0): Samsung SyncMaster (CRT-1): 400.0 MHz maximum pixel clock
(II) NVIDIA(0): Assigned Display Device: CRT-1
(II) NVIDIA(0): Validated modes:
(II) NVIDIA(0): "1280x1024"
(II) NVIDIA(0): "1024x768"
(II) NVIDIA(0): "800x600"
(II) NVIDIA(0): "640x480"
(II) NVIDIA(0): Virtual screen size determined to be 1280 x 1024
(--) NVIDIA(0): DPI set to (95, 96); computed from "UseEdidDpi" X config option
(II) NVIDIA(0): Setting mode "1280x1024"
(II) NVIDIA(0): NVIDIA 3D Acceleration Architecture Initialized
(II) NVIDIA(0): Using the NVIDIA 2D acceleration architecture
(==) NVIDIA(0): Backing store disabled
(==) NVIDIA(0): Silken mouse enabled
(**) NVIDIA(0): DPMS enabled
(II) XINPUT: Adding extended input device "NVIDIA Event Handler" (type: Other)
glxgears works with 5000 fps. I can run Xgl with no problem of speed and everything works perfect... I can see video...
Has anyone tried SciTE on a *nix box, and compared it to C::B on the same *nix box?
I may try to compile Scintilla and SciTE soon to see if it is slow....
I tried Scite and there are no problems like this. Typing-displaying character is instant, cpu-usage is low, scrolling etc are also acting normally. The only slowiness I saw on scite is when I tried to paste 1000 lines of C++ code from codeblocks to scite it took 5 seconds for scite to become responsible (and cpu usage went 100%)
Sque, I suggest you just give sysprof a try its not to hard to figure out how it works and would probably a good learning experience. Sysprof shows you a tree view of each running process and how much of its time was spent in each branch (each branch being a function with its subbranches being the functions it calls). You have to find the one which is codeblocks and go from there.
I already gave a try on Sysprof and as you can see on previous posts there are attachments of its log. What I can't understand is what kind of value is the number that displays. Time? calls? . If I assume that this is some type of time It seems that there is an abuse from libgdk-x11..., libpango and libcairo with libpango getting the leadership (4.12 self) after that libcairo. Inside codeblocks the only thing that takes time is DoPaint. So the problem is from DoPaint and child calls.
So! I made some changes on codeblocks source on the ScintillaWX::DoPaint to get some times
void ScintillaWX::DoPaint(wxDC* dc, wxRect rect) {
paintc++;
clock_t startClock, endClock ;
struct timeval now, start;
// Start timers
startClock = clock();
gettimeofday(&start, NULL);
printf("DoPaint(%d)",paintc);
paintState = painting;
Surface* surfaceWindow = Surface::Allocate();
surfaceWindow->Init(dc, wMain.GetID());
rcPaint = PRectangleFromwxRect(rect);
PRectangle rcClient = GetClientRectangle();
paintingAllText = rcPaint.Contains(rcClient);
dc->BeginDrawing();
ClipChildren(*dc, rcPaint);
Paint(surfaceWindow, rcPaint);
delete surfaceWindow;
if (paintState == paintAbandoned) {
// Painting area was insufficient to cover new styling or brace
// highlight positions
FullPaint();
}
paintState = notPainting;
dc->EndDrawing();
endClock = clock();
gettimeofday(&now, NULL);
printf("Time:CPU(%5.3f ms), REAL(%5.3f)\n",
((float)(endClock-startClock) / ((float)CLOCKS_PER_SEC/1000.0)),
(float)((float)now.tv_sec-start.tv_sec)*1000.0+((float)now.tv_usec-start.tv_usec)/1000.0
);
}
Here is the output on the console when
* Tapping the right arrow 5 times to move at a new location
DoPaint(1724)Time:CPU(120.000 ms), REAL(232.222)
DoPaint(1725)Time:CPU(0.000 ms), REAL(4.103)
DoPaint(1726)Time:CPU(110.000 ms), REAL(217.649)
DoPaint(1727)Time:CPU(0.000 ms), REAL(4.151)
DoPaint(1728)Time:CPU(100.000 ms), REAL(243.462)
DoPaint(1729)Time:CPU(0.000 ms), REAL(8.608)
DoPaint(1730)Time:CPU(100.000 ms), REAL(228.856)
DoPaint(1731)Time:CPU(0.000 ms), REAL(3.834)
DoPaint(1732)Time:CPU(150.000 ms), REAL(285.846)
* Writting the word: "12345" veryyy fast (in less than a second)
DoPaint(1872)Time:CPU(0.000 ms), REAL(2.006)
DoPaint(1873)Time:CPU(120.000 ms), REAL(193.427)
DoPaint(1874)Time:CPU(0.000 ms), REAL(2.551)
DoPaint(1875)Time:CPU(90.000 ms), REAL(185.037)
DoPaint(1876)Time:CPU(0.000 ms), REAL(2.171)
DoPaint(1877)Time:CPU(90.000 ms), REAL(205.687)
DoPaint(1878)Time:CPU(0.000 ms), REAL(2.036)
DoPaint(1879)Time:CPU(100.000 ms), REAL(189.700)
DoPaint(1880)Time:CPU(0.000 ms), REAL(12.403)
DoPaint(1881)Time:CPU(90.000 ms), REAL(191.264)
The wierd (at least for me) is that CPU times are greatly different than the real times. What I suspect is that the problem is on somekind of mutexs that consum time to lock-unlock. I checked on the sysprof log and the only mutexes that I found are inside libcairo. But... why only on some kind of PCs?