This is a problem I've had with an Nvidia GeForce 8400 GS video card, running Gnome 3 on Mageia 2 and using Aptana Studio 3.
Symptom: scrolling is unbearably slow - e.g. scrolling with the mouse wheel could take eight seconds to complete the scroll. Editing was also painful waiting for saves.
I know this is something to do with the Nvidia card as well as Aptana (see my solution) but has anyone else experienced this and have a better solution?
Best regards
Neill
New Solution to supercede one suggested below.
The problem seems to be a combination of JDK, nvidia, and gnome 3 (at least on Mageia 2 - not sure about Ubuntu etc). The best solution I got in the end was to use the nouveau driver without 3D acceleration, and then it works ok again. (With 3D acceleration nouveau currently seems to hang after about 5 minutes but in the meantime it ran Aptana fine.)
Netbeans seemed to have other problems instead, and the problem was also present in Eclipse. On KDE Aptana ran perfectly (quicker than on gnome at the best of times). So that is why I think JDK plus nvidia plus gnome 3 were not playing nicely.
An alternative solution is to use KDE instead for the desktop.
Old solution:
Solution of a sort: assuming you're using the 295.xxx nvidia driver (and not nouveau), then in Mageia control center->hardware->set up the graphical server, under options, turn OFF "Enable RENDER acceleration" where it warns having it on could cause problems with text rendering. Doing this seems to speed up Aptana back to pre-nvidia speeds.
However, X will now use up a large amount of CPU as it compensates for the lack of Render Acceleration. SO this is more of a work-around.
I've tried this with the latest nvidia beta release driver and the problem still remains.
It seems to be a combination of Aptana may be doing too much processing while scrolling, redrawing etc, the nvidia drivers with the text bug and gnome 3 being a bit slower. For example netbeans doesn't seem to have the same issue.
Related
I am trying to write a visualization that displays thousands of cubes/spheres/cones and allows you to pick one with the mouse. I can't use the multiple named mesh and raycasting approach because of all the draw calls and it was suggested I investigate instancing.
I found 2 examples that do something similar here and here but on my system they are unusably slow - less that 1Hz. The slowdown seems to be caused by this line. Without it, picking is broken of course but it runs at full speed. All the other examples run normally at a steady 60Hz.
My system is a MacBook Pro with an AMD Radeon R9 M370X.
Browser is Chrome Version 71.0.3578.80. Behaves the same way with Safari 12.0.1
Can anyone suggest a workaround or different approach I can investigate?
I have an application that plots quarter degree blocks on a map using Timage stacked on each other. I then add records by drawing them on a separate layer.
The problem I have is that Firemonkey (or Windows) scrambles the graphics, but only on some computers, and I think all the affected computers are laptops. See the following links for screenshots:
The correct image should look like this:
On laptops this scrambling may take 3 repaints of the layers, but sometimes (on exactly the same code) it happens after 1 or two times. While it is inconsistent in exactly how many repaints it takes, it is guaranteed to happen after no more than 3 paints.
So I have come to the conclusion that it must be a Graphics driver issue. I have a NVidia Geforce 950M on my laptop (Asus NJ551 with Windows 10), but if I understand the code correctly I am using the Windows Direct2D acceleration so the Nvidia drivers shouldn't affect things?
I set the following flag by default: GlobalUseDX10Software := true; //Use DirectX to generate graphics, but this does not seem to make any difference as it still scrambles even when set to false.
I would prefer the Windows acceleration as my users may not all have a graphics card installed. A friend using a HP laptop (not sure of the model but running Windows 8) does not experience the issue, yet another friend with a brand new HP laptop (low spec but with Windows 10) is also experiencing the issue.
Can someone please help out here? I am out of ideas, and I'm not even sure what to Google. Is it Windows 10, is it the Graphics driver, etc? Is there a way I can force my laptop to use the Graphics card for testing? While this will not help other users without proper graphics cards, it may help isolate the issue.
Any advice is appreciated!
From the EDN forum, I got the a number of other Graphics related global variables to set. The one that sorted out the issue is:
GlobalUseDXSoftware := True;
It now makes sense, as the issue started happening after moving to XE8 from XE5, and the GlobalUseDX10Software flag is now deprecated
I have problem with the autocomplete in ActionScript (Flash CS6), so I tried to change the IDE.Unfortunately I find Flashdevelop but it's a windows version.
Is there IDE for developping in ActionScript (Flash) on Mac osx.
You can try Intellij IDEA (is not free like FlashDevelop), I use it and it is better then Flash Builder(I used both) it is missing a UI designer(I think there is a plugin, the developers I know hand code the UI in mxml(drag dropping is for beginners) but a UI designer is useful sometimes.
If you want to spend money, checkout FDT, IntelliJ IDEA and Flash Builder. If you look for something free, there's a free very limited FDT version.
Other then that there also were some standard text editor which people enhanced with some basic dev functionality, for example:
http://www.sephiroth.it/python/sepy.php tried this some years ago and it was unstable on macs. might have improved since then.
Textmate
jEdit
VI http://vrichard86.wordpress.com/2012/12/02/how-to-write-your-own-as3-project-using-vi-and-how-to-compile-it-under-ubuntu-linux-actionscript-3-0/
If you really want to develop bigger projects on a mac I would suggest using one of the paid projects, since productivty with the free products usually is noticable lower.
I found Sublime Text 2 (mac osx) is very simple and useful in AS3 in addition to that the autocomplete is very fast.
I am encountering an issue where nothing is rendered when running a simple OpenGL application through VS 2012 on Windows 8.
I had a little debug renderer I was using to prototype some projects and had it up and running on Windows 7 using VS 2012 Express Edition.
I upgraded to Windows 8, and cloned the git repository with my work on. After installing the latest drivers and installing VS 2012, I ran my application, but nothing displayed, all I get is the screen clear colour. I was getting an exception before but that's because I didn't have the right drivers so when calling glGetIntegerv(GL_MAJOR_VERSION,...) I'd get -1 as OpenGL wasn't set up correctly. It is initialised correctly now and when stepping through, it looks like everything is working fine, the only problem is I'm not seeing anything.
To make sure it wasn't just my code I downloaded some of the Swiftless OpenGL examples and got the exact same thing. My application was using OpenGL 3.2 and no deprecated functionality. My hardware can support up to 3.3, and if it is of any use I am running Window 8 through Boot Camp on a Macbook air.
I have been bashing my head against a wall for the last couple of days trying to solve this but I'm not having much luck, I thought I'd throw it out there to see if anyone has had a similar problem, I'd be really grateful if anyone can offer any information. If someone with Windows 8 could download and build a simple OpenGL application though VS just to see if they can get something up on screen that would be interesting!
Do you use the good old and deprecated fixed function pipeline, namely immediate mode draw calls like glBegin(), glVertex*() and glEnd()? If so, try to draw your stuff using vertex arrays. Even if this doesn't help in your specific situation, immediate mode draw calls should be avoided at all cost to make the code forward compatible. The OpenGL 3.x core profile doesn't contain these old API functions anymore. I had also a blank screen on my new Win 7 notebook (OpenGL 3.3) because of some stale immediate mode draw calls (FTGL).
EDIT:
For independent GL debugging, I recommend this:
http://www.gremedy.com/
This program allows you to pause the execution and investigate buffer contents, shader programs and more.
After installing the latest drivers
Where did you get the drivers from? Only drivers you download directly from the GPU vendor's website ship with proper OpenGL support. The drivers automatically installed by Windows have only poor OpenGL support.
opengl support is not available for windows 8.their are still techniques to use it on windows its better to search on google coz i tried for minecraft game or u can check here too
I'm developing a very simple application for the Mac OSX platform making use of Qt and OpenGL (and QtOpenGL) so crossplatform gets easier.
The application receive a variable number of video streams that have to be rendered to the screen. Each frame of these video streams is used as a texture for mapping a rectangle in 3D space (very similar to a videowall).
Apart from the things such as receiving, locking, uploading video data, synchronizing threads... i consider it is clear that it's a quite simple application.
The fact is that all behaves ok when using cocoa based Qt 4.7 binaries (the default ones) in a 10.5 Mac.
But my code has to run fine at all of the OSX versions starting from (and including to) 10.4. So i tried the code in a 10.4 machine and it crashed just when starting. After a few hours of internet reading, i discovered that for a Qt Application to be targeted at 10.4, carbon Qt based has to be used. So i rebuild the whole project with the new framework.
When the new resulting binary gets run, all works well except by the fact that application's fps fall to about 2 fps!! And it behaves the same at both machines (10.5 computer has sensibly better features)
I've spent quite time working on this but i have not reached a solution. Any suggest?
More information about the application and things i've tried
code has not been modified when recompiling carbon based
only two (256x256 textures) videos ar used in order to assure it's not a bandwidth limit problem (although i know it shouldn't because the first code worked)
the 2 video streams arrive from network (local)
when a video stream arrives, a signal is emmited and the data will be uploaded to an OpenGL texture (glTexSubImage2D)
a timer makes render (paintGL) happen at about 20ms (~50 fps)
the render code use the textures (updated or not) to draw the rectangles.
rendering only when a video arrives won't work because of having 2 (asynchronous) video streams; besides more things have to be draw at screen.
only basic OpenGL commands are used (no PBO,FBO,VBO,...) The only one problematic thing could be the use of shaders (available only from Qt 4.7), but its code is trivial.
i've made use of OpenGLProfiler and Instruments. Nothing special/strange was observed.
Some things i suspect (conclusions)
it's clear it's not a hardware issue. The same computer behave differently
it gives me the sensation it's a threading/locking problem but, why?
carbon is 32 bits. The 10.5 application was 64. It's not possibly develop 64 bits in carbon.
for giving away the 32 bits possible cause, i also rebuild the first project for 32 bits. It worked partically the same.
i've read something about carbon having problems (more than usual) with context switching.
maybe OpenGL implementation is Multithread and code is not? (or the opposite?) That could cause a lot of stalls.
maybe carbon handle events differently from cocoa's? (i mean signal/event dispatching, main loop...)
Ok, this is (sorry for the so long writing) my actual headache. Any suggestion, idea.. would be very appreciated.
Thx in advance.
May I ask a diagnostic question? Can you ensure that it's not being passed to the software renderer?
I remember that when 10.4 was released, there was some confusion about quartz extreme, quartz and carbon, with some of it disabled, and hardware renderers disabled by default on some of them, which required configuration by the end user to get it working correctly. I'm not sure whether this information is pertinent, because you say that, having targetted 10.4, the problem exhibits on both the 10.4 and the 10.5, yes?
It's possible (though admittedly I'm grasping at straws here) that even in 10.5 carbon doesn't use the hardware renderers by default. I'd like to think though that OSX prefers hardware renderers to software renderers in all scenarios, but it may be worth spending a little time looking into, given how thoroughly you're already looking into other options.
Good luck.
If you are using Qt, I guess your code would work on a windows or linux platform. Have you tried your application under these platforms ?
This would quickly reveal if it comes from Qt or the mac OSX version.