On 9 Dec 97 at 23:43, William J. Deninger wrote: > It's wonderful that the OpenGL x3D view is run as a separate thread. No it is not correct. To Windows version of ROOT is 3 threads application: - Console thread - to accept keyboard input - Command thread - for CINT - Is it ROOT "MAIN" thread - Windows thread - to manage windows (X3D/OpenGL included) The problem is: Well all CINT commands go to "Command thread" but nothing prevent the user (clicking for example right-mouse) to call some PRE-COMPILED method directly from the Windows thread, and do avoid "Command Thread", and do delete (for example) some object the "Command thread" is working with at the same time. (Actually very "right-mouse" "Context menu" had been protected, but other methods may deliver this problem again and again). It never happens under UNIX since X-server is a separate process (not thread) and it has no direct access to ROOT object. > I've noticed however that if one is messing around with it > (zooming, rotation, etc) when the canvas view is updated, the CInt > process seems to stop running its program(seen by watching system > cpu monitor), and it goes into never never land. No errors, no > messages or any kind. No root prompt back. But the process will > have halted because my cpu becomes idle. > > Another troublesome bug is when the x3d view is first created. If > you move it before its done "working", or touch the canvas, the x3d > view locks. > > Is this something I should contact Bill Gates about? Probably. I had been spending quite a lot time trying to figure out which way OpenGL was implemented for Windows. Actually what is the level of the relationships between the "native" WIN32 Windows and OpenGL "rendering context". I found NO insight information. The only way was to inverstigate this system like a "black box" thing. Apparently it works if the user follows the "recommended" way. My impression it does create "time by time" some extra threads those are out of mycurrent ROOT control. The main ROOT problem - ROOT was done as a "Console Application" not as "WIN32 Windows Application". Two years there were the strong reasons to do so and it was only way. Again "in theory" there was no special with this approach at all. May be now we can re-think this approach. I'll appreciate alot someone may point me any references. I don't want to say the problem can not be solved. It could be and must be solved somebody. I'd like to notify some "global" problem for Windows version is still exist. Even more I believe the UNIX branch will face those too (as soon as TThread class will be used more/less widely). Solving this one will get really very very great Windows system. With my regards, Valery Dr. Valeri Faine (Valery Fine) ------------ ------------- Phone: +41 22 767 4921 CERN FAX : +41 22 767 7155 CH-1211 Geneva, 23 mailto:fine@mail.cern.ch Switzerland http://nicewww.cern.ch/~fine
This archive was generated by hypermail 2b29 : Tue Jan 04 2000 - 00:26:22 MET