from the earlier days of LG3D^? I have started contributing to LG3D^?. I have worked on debuging X11 Application and fixes a lot of bugs.
therefor I have gathered experience about the internal structure of LG3D^? code and know most of the code and how it work.

LG3D Platform
what I plan to do is
Schedule
Implementation details

LG3D^? Platform

Subject #* / Title

002 - *Multi-screen support

Description

Multiscreen enviroment is interessted by all users which work on CAD application or Presentation . Not to forget that the price of displays go allways cheaper and cheaper, which will end up to the fact that most user will have two screens or more in the near feature. thus LG3D^? should be ready to this.
LG3D is developed on top of Java 3D, which supports multi-screen environment. However, the LG3D^? part is not multi-screen ready yet. this let integration multiscreen in LG3D^? easer .

what I plan to do is

Part 1	make LG3D^? version of Xorg more ready for Multiscreen, the current is not totaly ready.
Part 2	LG3D^? should support 2 multiscreen mode. A- seperated screen mode. in this mode scence manager will control each available screen, but each screen is will not interface with each others. that mean 3D App and X11 can not be moved between screens. B- compined mode. in this mode 3D app and X11 app can be moved between screen. all screen will be seen by application as big one screen.

Schedule

July and August	implementing part 1 and 2B
August	implementing part 2A or just add infrastucture for how it can be implemented

Implementation details

I have discussed the possible Multiscreen Modes with the project owners and we have set the priorities for them as follow:

Mode 2 (combined mode): this mode has high priority and should be implemented and finished for SoC^?.
Mode 1a: in this mode all screens is running lg3d-session and the SceneManager^? control all screens but each screen is independent from others. this mode is not so interesting for now, but if we could put an initial implementation or how it could be implemented, is not bad.
Mode 1b: this mode is just a matter of user configuration of its KDE/GNOME or others Desktop Manager. LG3D^? only should run only on one screen in this mode.

Mode 2 details

This mode is the interesting part of LG3D^? and it will show how LG3D^? is so attractive. In Environments that has more than one screen the 3D space is enough to display big 3D application. To give LG3D^? a good support for multiscreen it need not just Java3D^? support, but it also support from Xorg Server.
Xorg can run in two mode also, the first mode is separated screens, in which a window is created on one screen cant be moved to another screen. The mouse pointer is still can move between screen. The second mode is Xinerama mode, this mode let all client see all screens as just big one screen. Java3D^? can also run in Xinerama, but this decrease the performance of openGL in this case.
Java3D^? has also the ability to combine all available screens (Xorg separated screens mode) to create one Virtual World, which expand to all screens, at the end result is one big screen. Here we benefit from Java3D^? performance, which will do the best optimizing for multiscreen, which was not possible if we run Xinerama.
From the point of view of our current modifications to Xorg to run LG3D^? with X11 native support, the cost of adding support to multiscreen in Xorg is small in compare to changes to be done on Xinerama X Extension which will duplicate some code if we run LG3D^? in a single screen without Xinerama mode.

Xorg modifications

for all above discussion there is a need for modification in current modified version of Xorg which run LG3D^? Session. All modifications will touch X Events System. In separate screen mode in Xorg, Xorg handle Pointer Grab very differently from when Xinerama is enabled. For example if you press a mouse button inside a window and started to drag the mouse so that it cross to second screen. Xorg will not let mouse pointer move to second screen. This a one example behaviour, which should be handle correctly when running LG3D^? in Combined mode, we should all mouse pointer to move as if Xinerama were enabled, so X11 App and 3D App can move between screens.

3D SceneManager^?

3D SceneManager^? define APIs which can be used to create rich 3D desktop Manager. You can see it like KDE/GNOME. Its APIs can be compared to X11 Window Manager Specifications, which define how 3D application can interface with LG3D^? Platform. One of its responsibility is give the Background Manager and the Taskbar the correct value for screen Width & height and others info which need to initialize the 3D Space.
therefor it need to detect how many screen we have and how it is layout. This information can be queried from the Display Manager, which is just an interface between LG3D^? APIs and Java3D^? APIs. From those infos we can calculate all need information like how much the end big screen width and height is. So it will be possible to add a 3D SceneManager^? Manager which support multiscreen Mode.

References

Here I want to add my discussion with LG3D^? project owners. Emails are ordered in their time.

Amir Bukhari
I want to support two Mode of operation in multiscreen.
Mode 1:
is seperated screen mode. The 3D sceneManager will control all available screen, but they 3D object should not move by moving them with mouse. And you could have in each screen a taskbar.
Mode 2:
compined mode, which work like Xinerama. This what you ask above "conflicts with Java 3D's assumption". In this Mode all screen act as one big screen.

Deron Johnson wrote:
Mode 1 is really two modes:
Mode 1a: All of the separate screens are running lg3d-session
Mode 1b: Some of the separate screens are running GNOME or KDE.
I would say the priority of your work should be:
#1 Mode 2 (combined mode)
#2 Mode 1a
#3 Mode 1b

Paul wrote:
I agree with Deron and Hideyas ordering.
Rgds
Paul

Amir Bukhari wrote:
Mode 1b is simple I have also test it with my current code base and it
work with KDE. GNOME doesn't work always, It seems I need to know how to configure it run only one screen. As you see mode 1b is a matter of user configuration of KDE/GNOME to run on free screen (screen that does not have Window Manager run on it).

Hideya Kawahara wrote:
For now (and for SoC^?) how about focusing on finishing up Mode 2?
This would include necessary modifications in the SceneManager^? API, and possibly development of a new SceneManager^?.
I understand difficulties in Mode 1a, but currently I think the benefit from it is not that great considering the >difficulties we face...
Hideya