X11 options on Ubuntu VM / Athens rendering problems
I'm running a fullscreen Pharo application on Ubuntu and I've noticed that Athens rendering gets way worse (maybe 10 updates per second) when I switch to fullscreen mode from inside Pharo. Ideally, I'd love for that to be fixed. In lieu of that, it would be cool if I could just maximize Pharo to the size of the screen to achieve good performance. Two things stop that: the Unity application bar and the title-bar. For the former, I can configure Unity to hide it. I noticed a '-notitle' X11 option when I execute pharo -help. I've tried using these X11 options and neither -notitle or -fullscreen seem to have any effect. Here's the command I run: ./bin/pharo --encoding utf8 -vm-display-X11 -fullscreen PATH_TO_IMAGE & Pharo starts fine but neither option seems to have any effect. I've also tried this in GNOME, thinking that Unity was the problem. Again, no effect. Any suggestions? Jeff
Hi Jeff Nice to see you. I do not know anybody running on X11. Esteban is working on better SDL20 integration. Did you try having a native window? I asked clement if he could release the Wizard Battle Arena because it was a game he did in a couple of days (yes he is good this guy) and that use cairo athens based for drawing on native window. stef On Fri, Sep 22, 2017 at 3:11 PM, J.F. Rick <self@je77.com> wrote:
I'm running a fullscreen Pharo application on Ubuntu and I've noticed that Athens rendering gets way worse (maybe 10 updates per second) when I switch to fullscreen mode from inside Pharo. Ideally, I'd love for that to be fixed.
In lieu of that, it would be cool if I could just maximize Pharo to the size of the screen to achieve good performance. Two things stop that: the Unity application bar and the title-bar. For the former, I can configure Unity to hide it. I noticed a '-notitle' X11 option when I execute pharo -help. I've tried using these X11 options and neither -notitle or -fullscreen seem to have any effect. Here's the command I run:
./bin/pharo --encoding utf8 -vm-display-X11 -fullscreen PATH_TO_IMAGE &
Pharo starts fine but neither option seems to have any effect. I've also tried this in GNOME, thinking that Unity was the problem. Again, no effect.
Any suggestions?
Jeff
Hi Stef, since I'm only doing Athens rendering, it might be possible to do a native window implementation. That said, I don't know how to get started with that. Documentation seems to be hard to find. The last time I saw any work on that it was too early to be usable. I'm also not sure if it solves my "it needs to run in fullscreen at full speed" problem. If someone like Clement could get me started, that would be awesome. Cheers, Jeff On Fri, Sep 22, 2017 at 12:27 PM Stephane Ducasse <stepharo.self@gmail.com> wrote:
Hi Jeff
Nice to see you. I do not know anybody running on X11. Esteban is working on better SDL20 integration. Did you try having a native window? I asked clement if he could release the Wizard Battle Arena because it was a game he did in a couple of days (yes he is good this guy) and that use cairo athens based for drawing on native window.
stef
On Fri, Sep 22, 2017 at 3:11 PM, J.F. Rick <self@je77.com> wrote:
I'm running a fullscreen Pharo application on Ubuntu and I've noticed that Athens rendering gets way worse (maybe 10 updates per second) when I switch to fullscreen mode from inside Pharo. Ideally, I'd love for that to be fixed.
In lieu of that, it would be cool if I could just maximize Pharo to the size of the screen to achieve good performance. Two things stop that: the Unity application bar and the title-bar. For the former, I can configure Unity to hide it. I noticed a '-notitle' X11 option when I execute pharo -help. I've tried using these X11 options and neither -notitle or -fullscreen seem to have any effect. Here's the command I run:
./bin/pharo --encoding utf8 -vm-display-X11 -fullscreen PATH_TO_IMAGE &
Pharo starts fine but neither option seems to have any effect. I've also tried this in GNOME, thinking that Unity was the problem. Again, no effect.
Any suggestions?
Jeff
Yes I will share a dropbox with you for now. On Sat, Sep 23, 2017 at 9:44 PM, J.F. Rick <self@je77.com> wrote:
Hi Stef,
since I'm only doing Athens rendering, it might be possible to do a native window implementation. That said, I don't know how to get started with that. Documentation seems to be hard to find. The last time I saw any work on that it was too early to be usable. I'm also not sure if it solves my "it needs to run in fullscreen at full speed" problem. If someone like Clement could get me started, that would be awesome.
Cheers,
Jeff
On Fri, Sep 22, 2017 at 12:27 PM Stephane Ducasse <stepharo.self@gmail.com> wrote:
Hi Jeff
Nice to see you. I do not know anybody running on X11. Esteban is working on better SDL20 integration. Did you try having a native window? I asked clement if he could release the Wizard Battle Arena because it was a game he did in a couple of days (yes he is good this guy) and that use cairo athens based for drawing on native window.
stef
On Fri, Sep 22, 2017 at 3:11 PM, J.F. Rick <self@je77.com> wrote:
I'm running a fullscreen Pharo application on Ubuntu and I've noticed that Athens rendering gets way worse (maybe 10 updates per second) when I switch to fullscreen mode from inside Pharo. Ideally, I'd love for that to be fixed.
In lieu of that, it would be cool if I could just maximize Pharo to the size of the screen to achieve good performance. Two things stop that: the Unity application bar and the title-bar. For the former, I can configure Unity to hide it. I noticed a '-notitle' X11 option when I execute pharo -help. I've tried using these X11 options and neither -notitle or -fullscreen seem to have any effect. Here's the command I run:
./bin/pharo --encoding utf8 -vm-display-X11 -fullscreen PATH_TO_IMAGE &
Pharo starts fine but neither option seems to have any effect. I've also tried this in GNOME, thinking that Unity was the problem. Again, no effect.
Any suggestions?
Jeff
Hi jeff let us know if this is working. the start.sh script is not working on my machine. but clement made it worked on his machine and he should publish a zip. Stef On Sun, Sep 24, 2017 at 9:39 AM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Yes I will share a dropbox with you for now.
On Sat, Sep 23, 2017 at 9:44 PM, J.F. Rick <self@je77.com> wrote:
Hi Stef,
since I'm only doing Athens rendering, it might be possible to do a native window implementation. That said, I don't know how to get started with that. Documentation seems to be hard to find. The last time I saw any work on that it was too early to be usable. I'm also not sure if it solves my "it needs to run in fullscreen at full speed" problem. If someone like Clement could get me started, that would be awesome.
Cheers,
Jeff
On Fri, Sep 22, 2017 at 12:27 PM Stephane Ducasse <stepharo.self@gmail.com> wrote:
Hi Jeff
Nice to see you. I do not know anybody running on X11. Esteban is working on better SDL20 integration. Did you try having a native window? I asked clement if he could release the Wizard Battle Arena because it was a game he did in a couple of days (yes he is good this guy) and that use cairo athens based for drawing on native window.
stef
On Fri, Sep 22, 2017 at 3:11 PM, J.F. Rick <self@je77.com> wrote:
I'm running a fullscreen Pharo application on Ubuntu and I've noticed that Athens rendering gets way worse (maybe 10 updates per second) when I switch to fullscreen mode from inside Pharo. Ideally, I'd love for that to be fixed.
In lieu of that, it would be cool if I could just maximize Pharo to the size of the screen to achieve good performance. Two things stop that: the Unity application bar and the title-bar. For the former, I can configure Unity to hide it. I noticed a '-notitle' X11 option when I execute pharo -help. I've tried using these X11 options and neither -notitle or -fullscreen seem to have any effect. Here's the command I run:
./bin/pharo --encoding utf8 -vm-display-X11 -fullscreen PATH_TO_IMAGE &
Pharo starts fine but neither option seems to have any effect. I've also tried this in GNOME, thinking that Unity was the problem. Again, no effect.
Any suggestions?
Jeff
Hi, I describe in the next paragraphs what I do to build application with Pharo at 50 fps. Now I am using a SDL2 window with OSWindow and not the default Pharo window for rendering. There is a fullscreen option with OSWindow, I don't use it but I've just tried it works fine. To use Athens/Cairo I start the VM headless and I open from the code a window using the SDL2 binding (OSWindow), then I extract the window surface as a cairo surface to draw on it using Athens and I use SDL2 to manage events (mouse, keyboard). That way I don't even start morphic/WorldMorph which wastes cpu ressources. I built this video game that way: https://clementbera.wordpress.com/2016/08/29/sdl2-cairo-headless-for-realtim... https://www.youtube.com/watch?v=srPdFgbyS6s The game is running in Pharo 4 (pre-Spur). I configured it to run at 50 fps but from time to time some frames are dropped for performance so I would say it is running at around 48-49 fps in practice. I think it should work on the latest Pharo but you need to ask on pharo-dev how to use OSWindow. Some APIs have changed since Pharo 4. Since the latest Pharo version is now using Spur I expect the performance to be way better and I think 50 fps is definitely manageable on a laptop. Note that this is still Pharo so if you want something which looks real-time you need to be careful about you object allocation rate in-between frame rendering. I hope this can help. Regards On Sun, Sep 24, 2017 at 9:43 AM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Hi jeff
let us know if this is working. the start.sh script is not working on my machine. but clement made it worked on his machine and he should publish a zip.
Stef
On Sun, Sep 24, 2017 at 9:39 AM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Yes I will share a dropbox with you for now.
On Sat, Sep 23, 2017 at 9:44 PM, J.F. Rick <self@je77.com> wrote:
Hi Stef,
since I'm only doing Athens rendering, it might be possible to do a native window implementation. That said, I don't know how to get started with that. Documentation seems to be hard to find. The last time I saw any work on that it was too early to be usable. I'm also not sure if it solves my "it needs to run in fullscreen at full speed" problem. If someone like Clement could get me started, that would be awesome.
Cheers,
Jeff
On Fri, Sep 22, 2017 at 12:27 PM Stephane Ducasse < stepharo.self@gmail.com> wrote:
Hi Jeff
Nice to see you. I do not know anybody running on X11. Esteban is working on better SDL20 integration. Did you try having a native window? I asked clement if he could release the Wizard Battle Arena because it was a game he did in a couple of days (yes he is good this guy) and that use cairo athens based for drawing on native window.
stef
On Fri, Sep 22, 2017 at 3:11 PM, J.F. Rick <self@je77.com> wrote:
I'm running a fullscreen Pharo application on Ubuntu and I've noticed that Athens rendering gets way worse (maybe 10 updates per second) when I switch to fullscreen mode from inside Pharo. Ideally, I'd love for that to
be
fixed.
In lieu of that, it would be cool if I could just maximize Pharo to the size of the screen to achieve good performance. Two things stop that: the Unity application bar and the title-bar. For the former, I can configure Unity to hide it. I noticed a '-notitle' X11 option when I execute pharo -help. I've tried using these X11 options and neither -notitle or -fullscreen seem to have any effect. Here's the command I run:
./bin/pharo --encoding utf8 -vm-display-X11 -fullscreen PATH_TO_IMAGE &
Pharo starts fine but neither option seems to have any effect. I've also tried this in GNOME, thinking that Unity was the problem. Again, no effect.
Any suggestions?
Jeff
Hi Clement and and Stef, thanks for sharing. The video looks cool and it seems like a high-performance approach. Unfortunately, it doesn't seem to be working in Linux. I'm attaching the Pharo debug file, but it seems like the Handler being OSNullWindowHandle indicates a problem. I'm also not sure that this approach would allow me to do fullscreen apps. I noticed that your video shows a title bar in MacOS. Cheers, Jeff On Sun, Sep 24, 2017 at 7:53 AM Clément Bera <bera.clement@gmail.com> wrote:
Hi,
I describe in the next paragraphs what I do to build application with Pharo at 50 fps. Now I am using a SDL2 window with OSWindow and not the default Pharo window for rendering. There is a fullscreen option with OSWindow, I don't use it but I've just tried it works fine.
To use Athens/Cairo I start the VM headless and I open from the code a window using the SDL2 binding (OSWindow), then I extract the window surface as a cairo surface to draw on it using Athens and I use SDL2 to manage events (mouse, keyboard). That way I don't even start morphic/WorldMorph which wastes cpu ressources.
I built this video game that way:
https://clementbera.wordpress.com/2016/08/29/sdl2-cairo-headless-for-realtim... https://www.youtube.com/watch?v=srPdFgbyS6s
The game is running in Pharo 4 (pre-Spur). I configured it to run at 50 fps but from time to time some frames are dropped for performance so I would say it is running at around 48-49 fps in practice. I think it should work on the latest Pharo but you need to ask on pharo-dev how to use OSWindow. Some APIs have changed since Pharo 4. Since the latest Pharo version is now using Spur I expect the performance to be way better and I think 50 fps is definitely manageable on a laptop.
Note that this is still Pharo so if you want something which looks real-time you need to be careful about you object allocation rate in-between frame rendering.
I hope this can help.
Regards
On Sun, Sep 24, 2017 at 9:43 AM, Stephane Ducasse <stepharo.self@gmail.com
wrote:
Hi jeff
let us know if this is working. the start.sh script is not working on my machine. but clement made it worked on his machine and he should publish a zip.
Stef
On Sun, Sep 24, 2017 at 9:39 AM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Yes I will share a dropbox with you for now.
On Sat, Sep 23, 2017 at 9:44 PM, J.F. Rick <self@je77.com> wrote:
Hi Stef,
since I'm only doing Athens rendering, it might be possible to do a native window implementation. That said, I don't know how to get started with that. Documentation seems to be hard to find. The last time I saw any work on that it was too early to be usable. I'm also not sure if it solves my "it needs to run in fullscreen at full speed" problem. If someone like Clement could get me started, that would be awesome.
Cheers,
Jeff
On Fri, Sep 22, 2017 at 12:27 PM Stephane Ducasse < stepharo.self@gmail.com> wrote:
Hi Jeff
Nice to see you. I do not know anybody running on X11. Esteban is working on better SDL20 integration. Did you try having a native window? I asked clement if he could release the Wizard Battle Arena because it was a game he did in a couple of days (yes he is good this guy) and that use cairo athens based for drawing on native window.
stef
On Fri, Sep 22, 2017 at 3:11 PM, J.F. Rick <self@je77.com> wrote:
I'm running a fullscreen Pharo application on Ubuntu and I've
noticed
that Athens rendering gets way worse (maybe 10 updates per second) when I switch to fullscreen mode from inside Pharo. Ideally, I'd love for that to be fixed.
In lieu of that, it would be cool if I could just maximize Pharo to the size of the screen to achieve good performance. Two things stop that: the Unity application bar and the title-bar. For the former, I can configure Unity to hide it. I noticed a '-notitle' X11 option when I execute pharo -help. I've tried using these X11 options and neither -notitle or -fullscreen seem to have any effect. Here's the command I run:
./bin/pharo --encoding utf8 -vm-display-X11 -fullscreen PATH_TO_IMAGE &
Pharo starts fine but neither option seems to have any effect. I've also tried this in GNOME, thinking that Unity was the problem. Again, no effect.
Any suggestions?
Jeff
On Mon, Sep 25, 2017 at 2:33 AM, J.F. Rick <self@je77.com> wrote:
Hi Clement and and Stef,
thanks for sharing. The video looks cool and it seems like a high-performance approach. Unfortunately, it doesn't seem to be working in Linux. I'm attaching the Pharo debug file, but it seems like the Handler being OSNullWindowHandle indicates a problem. I'm also not sure that this approach would allow me to do fullscreen apps. I noticed that your video shows a title bar in MacOS.
I've never made the demo work on linux, I am not surprised it doesn't work. This demo is based on the Pharo 4 OSWindow version, and more recent versions are working fine on linux. About fullscreen as I said in the previous mail it is possible to enable it, I tried it worked, but I did not do it as I don't think it make sense with this game. I will consider in the future making it work on the latest Pharo version on multiple OS if it makes sense to show people how to do it. I'm busy with other concerns right now. Anyway, it's just one approach, you can use another one.
Cheers,
Jeff
On Sun, Sep 24, 2017 at 7:53 AM Clément Bera <bera.clement@gmail.com> wrote:
Hi,
I describe in the next paragraphs what I do to build application with Pharo at 50 fps. Now I am using a SDL2 window with OSWindow and not the default Pharo window for rendering. There is a fullscreen option with OSWindow, I don't use it but I've just tried it works fine.
To use Athens/Cairo I start the VM headless and I open from the code a window using the SDL2 binding (OSWindow), then I extract the window surface as a cairo surface to draw on it using Athens and I use SDL2 to manage events (mouse, keyboard). That way I don't even start morphic/WorldMorph which wastes cpu ressources.
I built this video game that way: https://clementbera.wordpress.com/2016/08/29/sdl2-cairo- headless-for-realtime-native-applications/ https://www.youtube.com/watch?v=srPdFgbyS6s
The game is running in Pharo 4 (pre-Spur). I configured it to run at 50 fps but from time to time some frames are dropped for performance so I would say it is running at around 48-49 fps in practice. I think it should work on the latest Pharo but you need to ask on pharo-dev how to use OSWindow. Some APIs have changed since Pharo 4. Since the latest Pharo version is now using Spur I expect the performance to be way better and I think 50 fps is definitely manageable on a laptop.
Note that this is still Pharo so if you want something which looks real-time you need to be careful about you object allocation rate in-between frame rendering.
I hope this can help.
Regards
On Sun, Sep 24, 2017 at 9:43 AM, Stephane Ducasse < stepharo.self@gmail.com> wrote:
Hi jeff
let us know if this is working. the start.sh script is not working on my machine. but clement made it worked on his machine and he should publish a zip.
Stef
On Sun, Sep 24, 2017 at 9:39 AM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Yes I will share a dropbox with you for now.
On Sat, Sep 23, 2017 at 9:44 PM, J.F. Rick <self@je77.com> wrote:
Hi Stef,
since I'm only doing Athens rendering, it might be possible to do a native window implementation. That said, I don't know how to get started with that. Documentation seems to be hard to find. The last time I saw any work on that it was too early to be usable. I'm also not sure if it solves my "it needs to run in fullscreen at full speed" problem. If someone like Clement could get me started, that would be awesome.
Cheers,
Jeff
On Fri, Sep 22, 2017 at 12:27 PM Stephane Ducasse < stepharo.self@gmail.com> wrote:
Hi Jeff
Nice to see you. I do not know anybody running on X11. Esteban is working on better SDL20 integration. Did you try having a native window? I asked clement if he could release the Wizard Battle Arena because it was a game he did in a couple of days (yes he is good this guy) and that use cairo athens based for drawing on native window.
stef
On Fri, Sep 22, 2017 at 3:11 PM, J.F. Rick <self@je77.com> wrote:
I'm running a fullscreen Pharo application on Ubuntu and I've
noticed
that Athens rendering gets way worse (maybe 10 updates per second) when I switch to fullscreen mode from inside Pharo. Ideally, I'd love for that to be fixed.
In lieu of that, it would be cool if I could just maximize Pharo to the size of the screen to achieve good performance. Two things stop that: the Unity application bar and the title-bar. For the former, I can configure Unity to hide it. I noticed a '-notitle' X11 option when I execute pharo -help. I've tried using these X11 options and neither -notitle or -fullscreen seem to have any effect. Here's the command I run:
./bin/pharo --encoding utf8 -vm-display-X11 -fullscreen PATH_TO_IMAGE &
Pharo starts fine but neither option seems to have any effect. I've also tried this in GNOME, thinking that Unity was the problem. Again, no effect.
Any suggestions?
Jeff
Hi jeff you should give a try so that you can push esteban in his fight for a free host and strong SDL2.0 Stef On Mon, Sep 25, 2017 at 7:51 AM, Clément Bera <bera.clement@gmail.com> wrote:
On Mon, Sep 25, 2017 at 2:33 AM, J.F. Rick <self@je77.com> wrote:
Hi Clement and and Stef,
thanks for sharing. The video looks cool and it seems like a high-performance approach. Unfortunately, it doesn't seem to be working in Linux. I'm attaching the Pharo debug file, but it seems like the Handler being OSNullWindowHandle indicates a problem. I'm also not sure that this approach would allow me to do fullscreen apps. I noticed that your video shows a title bar in MacOS.
I've never made the demo work on linux, I am not surprised it doesn't work. This demo is based on the Pharo 4 OSWindow version, and more recent versions are working fine on linux.
About fullscreen as I said in the previous mail it is possible to enable it, I tried it worked, but I did not do it as I don't think it make sense with this game.
I will consider in the future making it work on the latest Pharo version on multiple OS if it makes sense to show people how to do it. I'm busy with other concerns right now.
Anyway, it's just one approach, you can use another one.
Cheers,
Jeff
On Sun, Sep 24, 2017 at 7:53 AM Clément Bera <bera.clement@gmail.com> wrote:
Hi,
I describe in the next paragraphs what I do to build application with Pharo at 50 fps. Now I am using a SDL2 window with OSWindow and not the default Pharo window for rendering. There is a fullscreen option with OSWindow, I don't use it but I've just tried it works fine.
To use Athens/Cairo I start the VM headless and I open from the code a window using the SDL2 binding (OSWindow), then I extract the window surface as a cairo surface to draw on it using Athens and I use SDL2 to manage events (mouse, keyboard). That way I don't even start morphic/WorldMorph which wastes cpu ressources.
I built this video game that way:
https://clementbera.wordpress.com/2016/08/29/sdl2-cairo-headless-for-realtim... https://www.youtube.com/watch?v=srPdFgbyS6s
The game is running in Pharo 4 (pre-Spur). I configured it to run at 50 fps but from time to time some frames are dropped for performance so I would say it is running at around 48-49 fps in practice. I think it should work on the latest Pharo but you need to ask on pharo-dev how to use OSWindow. Some APIs have changed since Pharo 4. Since the latest Pharo version is now using Spur I expect the performance to be way better and I think 50 fps is definitely manageable on a laptop.
Note that this is still Pharo so if you want something which looks real-time you need to be careful about you object allocation rate in-between frame rendering.
I hope this can help.
Regards
On Sun, Sep 24, 2017 at 9:43 AM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Hi jeff
let us know if this is working. the start.sh script is not working on my machine. but clement made it worked on his machine and he should publish a zip.
Stef
On Sun, Sep 24, 2017 at 9:39 AM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Yes I will share a dropbox with you for now.
On Sat, Sep 23, 2017 at 9:44 PM, J.F. Rick <self@je77.com> wrote:
Hi Stef,
since I'm only doing Athens rendering, it might be possible to do a native window implementation. That said, I don't know how to get started with that. Documentation seems to be hard to find. The last time I saw any work on that it was too early to be usable. I'm also not sure if it solves my "it needs to run in fullscreen at full speed" problem. If someone like Clement could get me started, that would be awesome.
Cheers,
Jeff
On Fri, Sep 22, 2017 at 12:27 PM Stephane Ducasse <stepharo.self@gmail.com> wrote:
Hi Jeff
Nice to see you. I do not know anybody running on X11. Esteban is working on better SDL20 integration. Did you try having a native window? I asked clement if he could release the Wizard Battle Arena because it was a game he did in a couple of days (yes he is good this guy) and that use cairo athens based for drawing on native window.
stef
On Fri, Sep 22, 2017 at 3:11 PM, J.F. Rick <self@je77.com> wrote:
I'm running a fullscreen Pharo application on Ubuntu and I've noticed that Athens rendering gets way worse (maybe 10 updates per second) when I switch to fullscreen mode from inside Pharo. Ideally, I'd love for that to be fixed.
In lieu of that, it would be cool if I could just maximize Pharo to the size of the screen to achieve good performance. Two things stop that: the Unity application bar and the title-bar. For the former, I can configure Unity to hide it. I noticed a '-notitle' X11 option when I execute pharo -help. I've tried using these X11 options and neither -notitle or -fullscreen seem to have any effect. Here's the command I run:
./bin/pharo --encoding utf8 -vm-display-X11 -fullscreen PATH_TO_IMAGE &
Pharo starts fine but neither option seems to have any effect. I've also tried this in GNOME, thinking that Unity was the problem. Again, no effect.
Any suggestions?
Jeff
i'm on ubuntu right now, so i could help with trying & testing things and/or diagnosing problems. Just tell me what to do -- Best regards, Igor Stasenko.
Igor I will share the dropbox for you. What would be great is to port the code of clement to Pharo 6.1 or even 70 to check SDL20 Esteban was integrating some of the code of ronie. Stef On Wed, Sep 27, 2017 at 1:05 PM, Igor Stasenko <siguctua@gmail.com> wrote:
i'm on ubuntu right now, so i could help with trying & testing things and/or diagnosing problems. Just tell me what to do
-- Best regards, Igor Stasenko.
On 27 September 2017 at 22:54, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Igor I will share the dropbox for you. What would be great is to port the code of clement to Pharo 6.1 or even 70 to check SDL20 Esteban was integrating some of the code of ronie.
Downloading.. Would be nice, if someone could give me short directions how to test it , what to run and what to expect. Because i am clearly was out of context for too long.
Stef
On Wed, Sep 27, 2017 at 1:05 PM, Igor Stasenko <siguctua@gmail.com> wrote:
i'm on ubuntu right now, so i could help with trying & testing things and/or diagnosing problems. Just tell me what to do
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
okay, first, i have to change the path to SDL2 library, because on my machine it's in /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0 but there's another trouble: browsing is incredibly slooow... First, i used finder to look for 'libSDL2-2.0.so.0' in sources. it took like 2 minutes to go through first few classes with starting A letter in their name. Then i lost temper, interrupted it and decided to browse into SDL bindings manually - clicked on OSWindow-SDL2 package... and its still 100% CPU and didn't opened while i typing this whole message. What is going on? Are .sources file corrupted or what? On 28 September 2017 at 01:27, Igor Stasenko <siguctua@gmail.com> wrote:
On 27 September 2017 at 22:54, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Igor I will share the dropbox for you. What would be great is to port the code of clement to Pharo 6.1 or even 70 to check SDL20 Esteban was integrating some of the code of ronie.
Downloading.. Would be nice, if someone could give me short directions how to test it , what to run and what to expect. Because i am clearly was out of context for too long.
Stef
On Wed, Sep 27, 2017 at 1:05 PM, Igor Stasenko <siguctua@gmail.com> wrote:
i'm on ubuntu right now, so i could help with trying & testing things and/or diagnosing problems. Just tell me what to do
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
apparently the SDL2 library is not in LD search path ldd libSDL2DisplayPlugin.so linux-gate.so.1 => (0xf77e9000) libSDL2-2.0.so.0 => not found ^^^^ libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf75dd000) /lib/ld-linux.so.2 (0x56573000) so it simply doesn't starts, so i installed sudo apt-get install libsdl2-2.0-0:i386 but then i found that i need to install 32-bit version of cairo as well.. but alas.. here is where i stuck: ---- sudo apt-get install libcairo2:i386 Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: libtheora0 : Depends: libcairo2 (>= 1.2.4) but it is not going to be installed E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages. ---- something in my installation are in conflict with 32-bit version of cairo.. that's weird.. but unmet dependencies/dependency conflict resolution of linux .deb packages is not my strong side. So, it would be nice if someone could help how to proceed with that. On 28 September 2017 at 01:41, Igor Stasenko <siguctua@gmail.com> wrote:
okay, first, i have to change the path to SDL2 library, because on my machine it's in /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0 but there's another trouble: browsing is incredibly slooow... First, i used finder to look for 'libSDL2-2.0.so.0' in sources. it took like 2 minutes to go through first few classes with starting A letter in their name. Then i lost temper, interrupted it and decided to browse into SDL bindings manually - clicked on OSWindow-SDL2 package... and its still 100% CPU and didn't opened while i typing this whole message.
What is going on? Are .sources file corrupted or what?
On 28 September 2017 at 01:27, Igor Stasenko <siguctua@gmail.com> wrote:
On 27 September 2017 at 22:54, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Igor I will share the dropbox for you. What would be great is to port the code of clement to Pharo 6.1 or even 70 to check SDL20 Esteban was integrating some of the code of ronie.
Downloading.. Would be nice, if someone could give me short directions how to test it , what to run and what to expect. Because i am clearly was out of context for too long.
Stef
On Wed, Sep 27, 2017 at 1:05 PM, Igor Stasenko <siguctua@gmail.com> wrote:
i'm on ubuntu right now, so i could help with trying & testing things and/or diagnosing problems. Just tell me what to do
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
imo, best what could be done is to forget about 32-bit version and use 64-bit VM & libs, to avoid problems like above. but for that, i need a 64-bit VM/image pair for a start, because one that you gave me is 32-bit.. and hence drags all the trouble with all this .so dependency zoo.. -- Best regards, Igor Stasenko.
Hi Igor, I got libsdl and libcairo 32bits installed fine on 64bits Ubuntu 17.04. What is your ubuntu system? Hilaire Le 28/09/2017 à 01:22, Igor Stasenko a écrit :
something in my installation are in conflict with 32-bit version of cairo.. that's weird.. but unmet dependencies/dependency conflict resolution of linux .deb packages is not my strong side. So, it would be nice if someone could help how to proceed with that.
-- Dr. Geo http://drgeo.eu
On 28 September 2017 at 12:43, Hilaire <hilaire@drgeo.eu> wrote:
Hi Igor,
I got libsdl and libcairo 32bits installed fine on 64bits Ubuntu 17.04.
weird..
What is your ubuntu system?
cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=17.04 DISTRIB_CODENAME=zesty DISTRIB_DESCRIPTION="Ubuntu 17.04"
Hilaire
Le 28/09/2017 à 01:22, Igor Stasenko a écrit :
something in my installation are in conflict with 32-bit version of cairo.. that's weird.. but unmet dependencies/dependency conflict resolution of linux .deb packages is not my strong side. So, it would be nice if someone could help how to proceed with that.
-- Dr. Geo http://drgeo.eu
-- Best regards, Igor Stasenko.
Beside the official ones, are you using alternate repositories? It can become a hell. In your posting, a Thoera dependency appeared... Hilaire Le 28/09/2017 à 19:51, Igor Stasenko a écrit :
I got libsdl and libcairo 32bits installed fine on 64bits Ubuntu 17.04.
weird..
-- Dr. Geo http://drgeo.eu
On 29 September 2017 at 11:23, Hilaire <hilaire@drgeo.eu> wrote:
Beside the official ones, are you using alternate repositories? It can become a hell.
In your posting, a Thoera dependency appeared...
it looks like there's an error in dependency spec. because i have 64-bit cairo installed, and uninstalling theora drags half of the desktop stuff after itself.. oh.. looks like i found why: sudo dpkg -i libcairo2_1.14.8-1_i386.deb Selecting previously unselected package libcairo2:i386. (Reading database ... 541684 files and directories currently installed.) Preparing to unpack libcairo2_1.14.8-1_i386.deb ... De-configuring libcairo2:amd64 (1.15.2-0intel1) ... Unpacking libcairo2:i386 (1.14.8-1) ... dpkg: error processing package libcairo2:i386 (--install): package libcairo2:i386 1.14.8-1 cannot be configured because libcairo2:amd64 is at a different version (1.15.2-0intel1) dpkg: error processing package libcairo2:amd64 (--install): package libcairo2:amd64 1.15.2-0intel1 cannot be configured because libcairo2:i386 is at a different version (1.14.8-1) Processing triggers for libc-bin (2.24-9ubuntu2.2) ... Errors were encountered while processing: now where the heck i can find binary of appropriate version libcairo2:i386 1.15.2 (googling doesn't helps)
Hilaire
Le 28/09/2017 à 19:51, Igor Stasenko a écrit :
I got libsdl and libcairo 32bits installed fine on 64bits Ubuntu 17.04.
weird..
-- Dr. Geo http://drgeo.eu
-- Best regards, Igor Stasenko.
libcairo2:amd64 1.15.2-0intel1 is clearly not from the official repository. See on my ubuntu17.04: hilaire@PCHome:~$ dpkg -l | grep libcairo2 ii libcairo2:amd64 1.14.8-1 amd64       Cairo 2D vector graphics library ii libcairo2:i386 1.14.8-1 i386        Cairo 2D vector graphics library ii libcairo2-dev 1.14.8-1 amd64       Development files for the Cairo 2D graphics library If you can wipe it out, you may sort out. Hilaire Le 29/09/2017 à 12:48, Igor Stasenko a écrit :
 package libcairo2:amd64 1.15.2-0intel1 cannot be configured because libcairo2:i386 is at a different version (1.14.8-1) Processing triggers for libc-bin (2.24-9ubuntu2.2) ...
-- Dr. Geo http://drgeo.eu
On 29 September 2017 at 22:05, Hilaire <hilaire@drgeo.eu> wrote:
libcairo2:amd64 1.15.2-0intel1 is clearly not from the official repository.
See on my ubuntu17.04:
hilaire@PCHome:~$ dpkg -l | grep libcairo2 ii libcairo2:amd64 1.14.8-1 amd64 Cairo 2D vector graphics library ii libcairo2:i386 1.14.8-1 i386 Cairo 2D vector graphics library ii libcairo2-dev 1.14.8-1 amd64 Development files for the Cairo 2D graphics library
If you can wipe it out, you may sort out.
most probably it is due to my attempts to make my hybrid graphics setup work.. i bought this laptop year ago and then figured out, that there are issues with X11 and kernel drivers that prevents using both video cards on board.. and installing latest & finest didn't changed much. -- Best regards, Igor Stasenko.
Hi Igor et al., thanks for taking a look at this. I appreciate it a lot. I've been swamped with work et al. but I'm back. If I understand it correctly, Igor is still fighting with drivers to make it work on his system. Let me know when you want me to try something. Cheers, Jeff On Fri, Sep 29, 2017 at 3:22 PM Igor Stasenko <siguctua@gmail.com> wrote:
On 29 September 2017 at 22:05, Hilaire <hilaire@drgeo.eu> wrote:
libcairo2:amd64 1.15.2-0intel1 is clearly not from the official repository.
See on my ubuntu17.04:
hilaire@PCHome:~$ dpkg -l | grep libcairo2 ii libcairo2:amd64 1.14.8-1 amd64 Cairo 2D vector graphics library ii libcairo2:i386 1.14.8-1 i386 Cairo 2D vector graphics library ii libcairo2-dev 1.14.8-1 amd64 Development files for the Cairo 2D graphics library
If you can wipe it out, you may sort out.
most probably it is due to my attempts to make my hybrid graphics setup work.. i bought this laptop year ago and then figured out, that there are issues with X11 and kernel drivers that prevents using both video cards on board.. and installing latest & finest didn't changed much.
-- Best regards, Igor Stasenko.
On 30 September 2017 at 17:51, J.F. Rick <self@je77.com> wrote:
Hi Igor et al.,
thanks for taking a look at this. I appreciate it a lot. I've been swamped with work et al. but I'm back. If I understand it correctly, Igor is still fighting with drivers to make it work on his system. Let me know when you want me to try something.
Sure. But i didn't done much, so there's nothing to appriciate yet :) But i want to help, if it won't require reinstalling OS, because i need my machine in working condition almost 24/7.. so i cannot take too much risk with it :( Cheers,
Jeff
--
Best regards, Igor Stasenko.
All these difficulties are good argument to get the appropriate libcairo/libpng shipped with the Linux VM, as done with Windows and MacOSX VM Hilaire Le 30/09/2017 à 21:58, Igor Stasenko a écrit :
Sure. But i didn't done much, so there's nothing to appriciate yet :) But i want to help, if it won't require reinstalling OS, because i need my machine in working condition almost 24/7.. so i cannot take too much risk with it :(
-- Dr. Geo http://drgeo.eu
Le 01/10/2017 à 09:26, Hilaire a écrit :
All these difficulties are good argument to get the appropriate libcairo/libpng shipped with the Linux VM, as done with Windows and MacOSX VM
This cause surprising problems in Pharo integration with the platform: for example, if you use a system library or an external command with Pharo as it is set now, that command will use Pharo libpng instead of the one it was compiled with (because pharo use of LD_LIBRARY_PATH will be inherited). Took me a while for example to understand that, when using the snap version of Pharo, Python3 scripts called from Pharo would be unable to import libraries such as numpy. But that works fine with the zeroinstall version of Pharo. Thierry
Hilaire
Le 30/09/2017 à 21:58, Igor Stasenko a écrit :
Sure. But i didn't done much, so there's nothing to appriciate yet :) But i want to help, if it won't require reinstalling OS, because i need my machine in working condition almost 24/7.. so i cannot take too much risk with it :(
On 1 October 2017 at 10:26, Hilaire <hilaire@drgeo.eu> wrote:
All these difficulties are good argument to get the appropriate libcairo/libpng shipped with the Linux VM, as done with Windows and MacOSX VM
Nah, in my case, there's nothing that can be lableled as "Pharo fault". It is definitely a linux/ubuntu ecosystem fault. - by not providing parallel updates for 32 & 64 bit variant of same library.
Hilaire
Le 30/09/2017 à 21:58, Igor Stasenko a écrit :
Sure. But i didn't done much, so there's nothing to appriciate yet :) But i want to help, if it won't require reinstalling OS, because i need my machine in working condition almost 24/7.. so i cannot take too much risk with it :(
-- Dr. Geo http://drgeo.eu
-- Best regards, Igor Stasenko.
I had situation where the system libcairo:i386 does not work with Dr.Geo[1], Pharo crashes with what looks like a Cairo crash! Looks like not a Pharo fault, but I am definitely stuck. It is problematic, it is a system (LinuxMint based) used in Geneva primary schools and Dr. Geo was expected to be used there :( Hilaire [1] http://forum.world.st/Cairo-related-crash-with-Dr-Geo-tt4952023.html Le 01/10/2017 à 19:50, Igor Stasenko a écrit :
All these difficulties are good argument to get the appropriate libcairo/libpng shipped with the Linux VM, as done with Windows and MacOSX VM
Nah, in my case, there's nothing that can be lableled as "Pharo fault". It is definitely a linux/ubuntu ecosystem fault. - by not providing parallel updates for 32 & 64 bit variant of same library.
-- Dr. Geo http://drgeo.eu
How could we help? On Sun, Oct 1, 2017 at 9:14 PM, Hilaire <hilaire@drgeo.eu> wrote:
I had situation where the system libcairo:i386 does not work with Dr.Geo[1], Pharo crashes with what looks like a Cairo crash! Looks like not a Pharo fault, but I am definitely stuck.
It is problematic, it is a system (LinuxMint based) used in Geneva primary schools and Dr. Geo was expected to be used there :(
Hilaire
[1] http://forum.world.st/Cairo-related-crash-with-Dr-Geo-tt4952023.html
Le 01/10/2017 à 19:50, Igor Stasenko a écrit :
All these difficulties are good argument to get the appropriate libcairo/libpng shipped with the Linux VM, as done with Windows and MacOSX VM
Nah, in my case, there's nothing that can be lableled as "Pharo fault". It is definitely a linux/ubuntu ecosystem fault. - by not providing parallel updates for 32 & 64 bit variant of same library.
-- Dr. Geo http://drgeo.eu
We tested it on P6.1 64bits, and this Cairo crash seems to be gone. It may need more testing though. Is it thanks to P6.1 or the 64bits image/VM? It looks strange because it looked like a lib Cairo crash, but in the other hand the faulty C function did not appear to be called from Pharo image. What need to be done porting to P6.1, is mainly image shrinking, fix of several bugs from P6.1 impacting drgeo, working setup for linux/windows/mac. Still some job. Hilaire Le 02/10/2017 à 15:19, Stephane Ducasse a écrit :
How could we help?
On Sun, Oct 1, 2017 at 9:14 PM, Hilaire<hilaire@drgeo.eu> wrote:
I had situation where the system libcairo:i386 does not work with Dr.Geo[1], Pharo crashes with what looks like a Cairo crash! Looks like not a Pharo fault, but I am definitely stuck.
It is problematic, it is a system (LinuxMint based) used in Geneva primary schools and Dr. Geo was expected to be used there:(
Hilaire
[1]http://forum.world.st/Cairo-related-crash-with-Dr-Geo-tt4952023.html
Le 01/10/2017 à 19:50, Igor Stasenko a écrit :
All these difficulties are good argument to get the appropriate libcairo/libpng shipped with the Linux VM, as done with Windows and MacOSX VM
Nah, in my case, there's nothing that can be lableled as "Pharo fault". It is definitely a linux/ubuntu ecosystem fault. - by not providing parallel updates for 32 & 64 bit variant of same library.
-- Dr. Geo http://drgeo.eu
-- Dr. Geo http://drgeo.eu
Just a quick follow up: We've found that if we are in fullscreen Pharo mode on Linux and hit the ALT button twice, the Athens-based rendering speeds up significantly. The first ALT brings the Unity launcher to the foreground. The second ALT bring fullscreen Pharo back to the foreground. I'm not sure why this makes Athens rendering faster but it does. Perhaps that offers a clue as to what is slowing Pharo down in fullscreen on Linux. Cheers, Jeff On Wed, Oct 11, 2017 at 2:56 PM Hilaire <hilaire@drgeo.eu> wrote:
We tested it on P6.1 64bits, and this Cairo crash seems to be gone. It may need more testing though.
Is it thanks to P6.1 or the 64bits image/VM? It looks strange because it looked like a lib Cairo crash, but in the other hand the faulty C function did not appear to be called from Pharo image.
What need to be done porting to P6.1, is mainly image shrinking, fix of several bugs from P6.1 impacting drgeo, working setup for linux/windows/mac. Still some job.
Hilaire
Le 02/10/2017 à 15:19, Stephane Ducasse a écrit :
How could we help?
On Sun, Oct 1, 2017 at 9:14 PM, Hilaire<hilaire@drgeo.eu> wrote:
I had situation where the system libcairo:i386 does not work with Dr.Geo[1], Pharo crashes with what looks like a Cairo crash! Looks like not a Pharo fault, but I am definitely stuck.
It is problematic, it is a system (LinuxMint based) used in Geneva primary schools and Dr. Geo was expected to be used there:(
Hilaire
[1]http://forum.world.st/Cairo-related-crash-with-Dr-Geo-tt4952023.html
Le 01/10/2017 à 19:50, Igor Stasenko a écrit :
All these difficulties are good argument to get the appropriate libcairo/libpng shipped with the Linux VM, as done with Windows and MacOSX VM
Nah, in my case, there's nothing that can be lableled as "Pharo
fault". It
is definitely a linux/ubuntu ecosystem fault. - by not providing parallel updates for 32 & 64 bit variant of same library. -- Dr. Geo http://drgeo.eu
-- Dr. Geo http://drgeo.eu
I donât have any issues with Linux in full screen mode (Mint 18 KDE and OEL7 UEK KDE) but it sounds like it may be an issue with the Wayland graphics system, and KDE doesnât use it AFAIK. If so, it may also be driver specific â what graphics card are you using? It is just a guess, but pulling Unity forward switches it out of Wayland graphics mode (used mainly for games etc. that run full screen), if it doesnât go back into it until a new full screen app starts up it would account for the improvement. Andrew Sent from Mail for Windows 10 From: J.F. Rick Sent: Monday, November 6, 2017 4:57 PM To: Any question about pharo is welcome Subject: Re: [Pharo-users] X11 options on Ubuntu VM / Athens renderingproblems Just a quick follow up: We've found that if we are in fullscreen Pharo mode on Linux and hit the ALT button twice, the Athens-based rendering speeds up significantly. The first ALT brings the Unity launcher to the foreground. The second ALT bring fullscreen Pharo back to the foreground. I'm not sure why this makes Athens rendering faster but it does. Perhaps that offers a clue as to what is slowing Pharo down in fullscreen on Linux. Cheers, Jeff On Wed, Oct 11, 2017 at 2:56 PM Hilaire <hilaire@drgeo.eu> wrote: We tested it on P6.1 64bits, and this Cairo crash seems to be gone. It may need more testing though. Is it thanks to P6.1 or the 64bits image/VM? It looks strange because it looked like a lib Cairo crash, but in the other hand the faulty C function did not appear to be called from Pharo image. What need to be done porting to P6.1, is mainly image shrinking, fix of several bugs from P6.1 impacting drgeo, working setup for linux/windows/mac. Still some job. Hilaire Le 02/10/2017 à 15:19, Stephane Ducasse a écrit :
How could we help?
On Sun, Oct 1, 2017 at 9:14 PM, Hilaire<hilaire@drgeo.eu>Â wrote:
I had situation where the system libcairo:i386 does not work with Dr.Geo[1], Pharo crashes with what looks like a Cairo crash! Looks like not a Pharo fault, but I am definitely stuck.
It is problematic, it is a system (LinuxMint based) used in Geneva primary schools and Dr. Geo was expected to be used there:(
Hilaire
[1]http://forum.world.st/Cairo-related-crash-with-Dr-Geo-tt4952023.html
Le 01/10/2017 à 19:50, Igor Stasenko a écrit :
   All these difficulties are good argument to get the appropriate    libcairo/libpng shipped with the Linux VM, as done with Windows    and MacOSX VM
Nah, in my case, there's nothing that can be lableled as "Pharo fault". It is definitely a linux/ubuntu ecosystem fault. - by not providing parallel updates for 32 & 64 bit variant of same library. -- Dr. Geo http://drgeo.eu
-- Dr. Geo http://drgeo.eu
Interesting. Could be. The specific problem came up on an Intel NUC which uses Intel integrated graphics. Cheers, Jeff On Mon, Nov 6, 2017 at 5:24 PM Andrew Glynn <aglynn42@gmail.com> wrote:
I donât have any issues with Linux in full screen mode (Mint 18 KDE and OEL7 UEK KDE) but it sounds like it may be an issue with the Wayland graphics system, and KDE doesnât use it AFAIK. If so, it may also be driver specific â what graphics card are you using?
It is just a guess, but pulling Unity forward switches it out of Wayland graphics mode (used mainly for games etc. that run full screen), if it doesnât go back into it until a new full screen app starts up it would account for the improvement.
Andrew
Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10
*From: *J.F. Rick <self@je77.com> *Sent: *Monday, November 6, 2017 4:57 PM *To: *Any question about pharo is welcome <pharo-users@lists.pharo.org> *Subject: *Re: [Pharo-users] X11 options on Ubuntu VM / Athens renderingproblems
Just a quick follow up: We've found that if we are in fullscreen Pharo mode on Linux and hit the ALT button twice, the Athens-based rendering speeds up significantly. The first ALT brings the Unity launcher to the foreground. The second ALT bring fullscreen Pharo back to the foreground. I'm not sure why this makes Athens rendering faster but it does. Perhaps that offers a clue as to what is slowing Pharo down in fullscreen on Linux.
Cheers,
Jeff
On Wed, Oct 11, 2017 at 2:56 PM Hilaire <hilaire@drgeo.eu> wrote:
We tested it on P6.1 64bits, and this Cairo crash seems to be gone. It may need more testing though.
Is it thanks to P6.1 or the 64bits image/VM? It looks strange because it looked like a lib Cairo crash, but in the other hand the faulty C function did not appear to be called from Pharo image.
What need to be done porting to P6.1, is mainly image shrinking, fix of several bugs from P6.1 impacting drgeo, working setup for linux/windows/mac. Still some job.
Hilaire
Le 02/10/2017 à 15:19, Stephane Ducasse a écrit :
How could we help?
On Sun, Oct 1, 2017 at 9:14 PM, Hilaire<hilaire@drgeo.eu> wrote:
I had situation where the system libcairo:i386 does not work with Dr.Geo[1], Pharo crashes with what looks like a Cairo crash! Looks like not a Pharo fault, but I am definitely stuck.
It is problematic, it is a system (LinuxMint based) used in Geneva primary schools and Dr. Geo was expected to be used there:(
Hilaire
[1]http://forum.world.st/Cairo-related-crash-with-Dr-Geo-tt4952023.html
Le 01/10/2017 à 19:50, Igor Stasenko a écrit :
All these difficulties are good argument to get the appropriate libcairo/libpng shipped with the Linux VM, as done with Windows and MacOSX VM
Nah, in my case, there's nothing that can be lableled as "Pharo
fault". It
is definitely a linux/ubuntu ecosystem fault. - by not providing parallel updates for 32 & 64 bit variant of same library. -- Dr. Geo http://drgeo.eu
-- Dr. Geo http://drgeo.eu
If you stored the settings without full screen mode checked, start up Pharo, then switch in into full screen mode, it should run at full performance if Iâm right. I have an intel integrated card + an NVidia, it can work in either mode or in Optimus mode, where it only goes into NVidia if an app requests it or goes full screen. Pharo is very quick in full screen as a result, since I run it in Optimus mode (Linux has issues with the windowing system using the NVidia drivers in normal mode). Since Pharo uses SDL2 for the base graphic subsystem, which is one of the main gaming graphics platforms, it wouldnât be surprising if Wayland assumed it was a game if it starts full screen, and intel graphics arenât all that great for gaming (so Iâve heard â I have an Xbox with one game â FIFA, lol). Andrew Glynn From: J.F. Rick Sent: Saturday, November 18, 2017 3:06 PM To: Any question about pharo is welcome Subject: Re: [Pharo-users] X11 options on Ubuntu VM / Athens renderingproblems Interesting. Could be. The specific problem came up on an Intel NUC which uses Intel integrated graphics. Cheers, Jeff On Mon, Nov 6, 2017 at 5:24 PM Andrew Glynn <aglynn42@gmail.com> wrote: I donât have any issues with Linux in full screen mode (Mint 18 KDE and OEL7 UEK KDE) but it sounds like it may be an issue with the Wayland graphics system, and KDE doesnât use it AFAIK. If so, it may also be driver specific â what graphics card are you using?  It is just a guess, but pulling Unity forward switches it out of Wayland graphics mode (used mainly for games etc. that run full screen), if it doesnât go back into it until a new full screen app starts up it would account for the improvement.  Andrew  Sent from Mail for Windows 10  From: J.F. Rick Sent: Monday, November 6, 2017 4:57 PM To: Any question about pharo is welcome Subject: Re: [Pharo-users] X11 options on Ubuntu VM / Athens renderingproblems  Just a quick follow up: We've found that if we are in fullscreen Pharo mode on Linux and hit the ALT button twice, the Athens-based rendering speeds up significantly. The first ALT brings the Unity launcher to the foreground. The second ALT bring fullscreen Pharo back to the foreground. I'm not sure why this makes Athens rendering faster but it does. Perhaps that offers a clue as to what is slowing Pharo down in fullscreen on Linux.  Cheers,  Jeff  On Wed, Oct 11, 2017 at 2:56 PM Hilaire <hilaire@drgeo.eu> wrote: We tested it on P6.1 64bits, and this Cairo crash seems to be gone. It may need more testing though. Is it thanks to P6.1 or the 64bits image/VM? It looks strange because it looked like a lib Cairo crash, but in the other hand the faulty C function did not appear to be called from Pharo image. What need to be done porting to P6.1, is mainly image shrinking, fix of several bugs from P6.1 impacting drgeo, working setup for linux/windows/mac. Still some job. Hilaire Le 02/10/2017 à 15:19, Stephane Ducasse a écrit :
How could we help?
On Sun, Oct 1, 2017 at 9:14 PM, Hilaire<hilaire@drgeo.eu>Â wrote:
I had situation where the system libcairo:i386 does not work with Dr.Geo[1], Pharo crashes with what looks like a Cairo crash! Looks like not a Pharo fault, but I am definitely stuck.
It is problematic, it is a system (LinuxMint based) used in Geneva primary schools and Dr. Geo was expected to be used there:(
Hilaire
[1]http://forum.world.st/Cairo-related-crash-with-Dr-Geo-tt4952023.html
Le 01/10/2017 à 19:50, Igor Stasenko a écrit :
   All these difficulties are good argument to get the appropriate    libcairo/libpng shipped with the Linux VM, as done with Windows    and MacOSX VM
Nah, in my case, there's nothing that can be lableled as "Pharo fault". It is definitely a linux/ubuntu ecosystem fault. - by not providing parallel updates for 32 & 64 bit variant of same library. -- Dr. Geo http://drgeo.eu
-- Dr. Geo http://drgeo.eu Â
Have you tried a full update cycle of your system? apt-get update apt-get dist-upgrade Hilaire Le 28/09/2017 à 01:22, Igor Stasenko a écrit :
So, it would be nice if someone could help how to proceed with that.
-- Dr. Geo http://drgeo.eu
participants (7)
-
Andrew Glynn -
Clément Bera -
Hilaire -
Igor Stasenko -
J.F. Rick -
Stephane Ducasse -
Thierry Goubier