Full Version: Moi and Ubuntu

Show messages:  1-7  8-27  28-47  48-67  68-87  88-105

Hi David, those messages are not really significant errors.

For example this one:
SHAppBarMessage(ABM_GETAUTOHIDEBAR, hwnd=(nil), edge=0): stub

This message means that WINE does not implement the shell method that returns back whether there are any auto-hide taskbars set in the Windows desktop. MoI calls that method when you maximize its window to figure out whether to leave a little 2 pixel space on any side of the window where an auto-hiding taskbar is at, so that they can still pop up when you move the mouse to that side of the monitor.

There is not really any mechanism for auto-hide taskbars in WINE, so it's not really a problem that it does not implement that particular windows mechanism.

The other messages are similar - when you draw a line MoI will have some inter-process communication between moi_commandprocessor.exe where the script actually executes, and MoI.exe - that's what those ones like
IRemUnknown_RemQueryInterface failed with error 0x80004002
are about, but that particular call is one that is again not an actual error, it's normal for this particular query interface call to fail in that particular instance.


So none of those messages that you show there seem like they are any particular cause for concern themselves.


Do you possibly have any kind of special anti-virus program also running that might be intercepting inter-process communication ?

- Michael

---

Hi David - I guess it could be possible that just the display of those messages to the console is itself taking some amount of extra time.

I'll see if I can tweak things a bit to avoid that level of chatter on the console, maybe that will help a bit.

How long of a delay are you seeing, is it something like a quick hiccup or more like a couple of seconds or what?

- Michael

---

Ufff, I'd like that those messages adviced that anything really important. At least I would have any clue.

I haven't got any antivirus program installed.

Maybe the graphic card is not powerful enough?

---

Well, if I start MoI from the Icon -without console- I get more or less the same delay.

It's like a quick hiccup. The delay just for don't feel comfortable.

I have just opened a 14 mb file, and I perceive a more delay.

Almost all, when I put the pointer over an object looking for its "object snap" and then when I rotate in 3d viewport.

About this, in small files it doesn't flow fine (there are small leaps) but in the 14 mb files, the rotate is unhandling (big leaps and I can't control the moment to stop the rotation)

---

Hi David, well that kind of stuff that you're describing sounds like problems with the video driver.

Poor video driver quality seems to be a big problem with trying to get 3D apps running on Linux.

You might try switching to an older version of the proprietary nVidia driver to see if one of the old versions behaves better for you.

- Michael

---

Hello Michael:

Then, there are nothing I can do. :-(

Thank you!

---

Hi David,

> Then, there are nothing I can do. :-(

You can try removing your current proprietary driver and instead installing an older version of it - that could possibly avoid whatever glitch is happening in your current version.

- Michael

---

Fascinating thread. I left Ubuntu some time ago because no CAD software worked on it. Hopefully this has changed. I am downloading 11.10 as we speak...

Excited...

---

Incidentally, what winetricks will I need?

---

Hi bigseb - for MoI v3 you don't need any winetricks installed at all, you just need a good enough video driver, that seems to be the biggest potential obstacle.

- Michael

---

Dear Michael,

finally I got the time to compile wine on my MacBook (running OSX 10.6.8). Using the osxwinebuilder script turned out pretty straight forward, nice tool that is. I got a Wine 1.3.32 out of it based on the recent XQuartz 2.7.0 as X11 server. Then I used the winetricks d3d9x_43, gdiplus and ie8 as suggested by Roger.

When I start the Moi trial I can see some of the tool icons for the fraction of a second but then everything disappears again... similar than with my previous tests on a DELL notebook running Debian Linux.

I have attached the trace, perhaps you can conclude something that helps.

Thank you very much for your time,
Chyman

Attachments:
wdbg.txt

---

Hi Chyman, thanks for testing with Wine on OSX! I've actually been testing with it recently myself and I found that the method that Wine uses for rendering Direct3D content into child windows does not work properly on OSX - that's why the regular MoI build does not work properly.

But it looks like I will probably be able to make a few minor adjustments to how MoI sets up its 3D viewports to avoid this problem, I should know more details within the next week or so for if that is going to work well or not.

- Michael

---

Thank you, Michael, this sounds very promising.
I am looking forward to that very much!

Thanks again,
Chyman

---

Dear Michael,

I also had a quick test of Moi in a WinXP Pro 64 VM under VMware Player 3.1.4 on my Ubuntu 11.04 laptop today. There I got a strange effect in the Split view: The 4 views always showed identical content like all 4 were Top view or all 4 were 3D view and so on... flipping over on mouse moves, see attached screen-shot.
I don't know if that is of any help, just meant to share it with you in case...

Kind greetings,
Chyman

Image Attachments:
moi-vm.png 

---

Hi Chyman - that's almost certainly a bug in VMWare Player's Direct3D system.

In order to conserve video memory MoI normally only actually uses a single swapchain for the split view and redirects it as needed to the current viewport that's being drawn at that moment. That's totally supported by the real Direct3D system but it seems that Wine's Direct3D layer doesn't like to render a swapchain to different windows like that and sort of wants to lock each swapchain down to only being displayed in a single window.

I've been doing some work recently to make an option to use a separate swapchain for each individual viewport window instead of only using a single one which should help to avoid this bug.

- Michael

---

Hi Michael,

thank you for giving a detailed explanation. The VMWare Player was just a quick side test, I would rather prefer a Wine solution than a VM one.

I have posted my Wine problem also on the WineHQ forum since it behaves the same with a simple OpenGL test (qtgears.exe):
http://forum.winehq.org/viewtopic.php?t=12426&start=0&postdays=0&postorder=asc&highlight=

Perhaps we are lucky and there are enhancements for how Wine's OpenGL and XQuartz interact...
Chyman

---

Hi Chyman,

> I have posted my Wine problem also on the WineHQ forum
> since it behaves the same with a simple OpenGL test
> (qtgears.exe):

Do you know if that program renders its OpenGL content into a child window instead of directly into a top level window?

Because it's that "render to child window" code path in Wine that seems to not function properly on OSX - it seems to need some particular kind of OpenGL extension that Apple does not happen to implement.


> Perhaps we are lucky and there are enhancements for
> how Wine's OpenGL and XQuartz interact...

For MoI's case I don't think any enhancements will be needed, because it looks like I'm going to be able to make a few pretty small modifications to how MoI's viewports are structured so that they will get a regular X window associated with each one and will then avoid the bad render-to-child-window code path that does not work under OSX.

That also combined with another slight modification to have a separate swapchain for each window instead of trying to share a single one seems to pretty much avoid the Direct3D/OpenGL problems entirely.

There only seem to be a few little remaining glitches in some of the UI to still clear up.

- Michael

---

Hi Michael,

the qtgears.exe is available from http://lab.bachem-it.com/opengl/qtgears
It is based on mesa's glxgears and also provides the source code there. Unfortunately I am not fluent enough in C++ to tell, sorry...

If you happen to know a simple Wine Direct3D/OpenGL application that renders into a regular X window I could probably make a test from the "other side"...

Which versions of Wine and XQuartz/X11 have you been testing with? What type of Mac and OS X version are you running on, if I may ask?

Thank you for all those efforts!
Chyman

---

Hi Chyman - I took a look at qtgears.exe using a window examination utility and the render window is indeed a child window - the menu bar, render area and bottom status bar are all separate child windows.

So most likely it is that whole issue with OpenGL rendering into child windows not working correctly with Wine under OSX that is causing qtgears.exe from not working right.


> If you happen to know a simple Wine Direct3D/OpenGL
> application that renders into a regular X window I could
> probably make a test from the "other side"...

I've attached a sample program from the Direct3D9 SDK - because it renders directly to a top level window and not into a child window you will probably find that it works ok, unless you have an old version of Wine maybe.


> Which versions of Wine and XQuartz/X11 have you been
> testing with?

Wine version is 1.3.32. XQuartz version is whatever version comes with Wineskin, I think it's a slightly older and slightly modified version of XQuartz.

The part that's good about using Wineskin is that it puts all of Wine, XQuartz and the app itself all together into one self-contained application bundle that can be run directly like a regular OSX app, so it avoids any need to set up Wine or XQuartz separately. Being based off of this should help for stability quite a bit because I won't have to deal with variations in Wine or XQuartz.


> What type of Mac and OS X version are you running on, if I may ask?

I'm on a current generation Mac Mini using OSX 10.7 Lion. This stuff should work on OSX 10.6 as well but I don't think it is going to work on 10.5 or earlier.

- Michael

Attachments:
HDRCubeMap.zip

---

Hi Michael,

thank you for examining the qtgears.exe, so that explains why it behaves very similar to MoI although it's GUI is so much simpler.

Thank you also for providing a sample program from the Direct3D9 SDK, I tried to run it but got a "Could not find any compatible Direct3D devices." message shortly after all pixel formats have been queried. Not sure what is going wrong this time... I am using Wine version 1.3.32 too... perhaps the Intel GMA X3100 hardware is a problem...

Your description of Wineskin sounds a bit like Winebottler you mentioned previously, that bundling is indeed of advantage for creating a defined environment, I will have a closer look at it.

Many thanks,
Chyman

---

Show messages:  1-7  8-27  28-47  48-67  68-87  88-105