Messages

31

General discussions / Re: Clipboard support on Linux: A few hiccups.

« on: October 09, 2014, 07:57:22 am »

Is there a possibility to check in a non-blocking call whether the clipboard is ready?

If so, an asynchronous (but single-threaded) algorithm would still be possible: setClipboard() just issues the order and caches the text. In regular intervals (probably in a window event loop), the clipboard is checked for availability, and set if available.

That's what's being done right now. This means a non-static member function, and apparently that's wrong and makes for a horrible API. If not for this, the implementation on X11 is finished. Setting the clipboard doesn't require any event loops, it's just that to set the clipboard, you must own the clipboard, and if you own the clipboard, you need to respond to people requesting the clipboard's contents. The clipboard is thus always available, since all you're doing when you set it is taking ownership and setting your cache. No waiting involved.

Take a look at https://github.com/Mischa-Alff/SFML/blob/feature/clipboard/src/SFML/Window/Unix/WindowImplX11.cpp#L589
There's no waiting in there. All the clipboard-ownership burden stuff is in WindowImplX11::processEvent(); https://github.com/Mischa-Alff/SFML/blob/feature/clipboard/src/SFML/Window/Unix/WindowImplX11.cpp#L1352
And thus that code gets a chance to be run at regular intervals, which is what is needed.

The problem is that SFML must also send the clipboard contents to other applications when they request it.

Can you at least try to contribute to the discussion if you're going to post?

32

General discussions / Re: Clipboard support on Linux: A few hiccups.

« on: October 08, 2014, 10:19:26 pm »

I think spawning a new thread for handling the clipboard window is the lesser evil of these two.  Clipboard ownership probably won't be requested until the user tries to copy something in another program, so a blocking setter would cause the program hang until the user gives up and starts doing something else. Requiring the user to copy something in another application to make the program responsive again is bad.

I only suggested it as a potential solution to show how ridiculous a potential solution would be. There is no real, simple solution to this, and the kinds of workarounds I suggested are purely to reinforce this point.

If somehow dedicating a thread to the clipboard of all things seems sane to everyone, then that's the method we'll go with, but I think that's utterly insane and a waste of resources.

33

General discussions / Re: Clipboard support on Linux: A few hiccups.

« on: October 08, 2014, 04:48:52 pm »

Theoretically, getting the clipboard is quite fast, as long as the selection owner has a quick response (which is not guaranteed). This is why the current implementation on X11 has a 1-second time limit, and if that isn't met, it returns the cache.

Getting the clipboard is totally possible in a static function etc. It's setting the clipboard in a static function that's nearly impossible. Since you can't give ownership of the selection to another window, you're stuck with it and the requirement to send its contents to anybody who requests them, until someone else requests ownership. Either we could make the setClipboard function forking, like xclip does, and thus spawning an entire thread just for the sake of responding to events (until we get a SelectionClear event), or we could make it blocking and have the program wait an undetermined amount of time until the hidden window's ownership of the clipboard has been lifted.

As for performance, I don't know about you, but I easily laugh and criticize software when simple things such as clipboard usage make the whole thing lock up for even half a second. It shouldn't happen, and it doesn't have to happen, either. And if we're talking about a game, which should run at 30/60/120 FPS, having the framerate drop to 10 or 20 FPS (stutter) because the game used the clipboard is pretty bad.


I ran some tests, in microseconds (us), with 1000000 samples, on my i7 4770 (per call):

Code: [Select]

Times (min, max, avg): Get Clipboard (6, 36462, 90), Set Clipboard (15, 198679, 215).
The current method thus doesn't seem to pose a performance issue.

34

General discussions / Re: Clipboard support on Linux: A few hiccups.

« on: October 06, 2014, 06:09:56 pm »

I think creating a new event is fairly un-intuitive, when all the other libraries simply have get/setClipboard functions that are synchronous.

Plus this would only be worth it on Linux, since, as Tank said, other OSes all have synchronous clipboard management.

35

General discussions / Re: Clipboard support on Linux: A few hiccups.

« on: October 06, 2014, 07:04:00 am »

As far as I understood, you enter an event loop in getClipboard and wait for the proper message from X with the requested information (selection owner notify). Isn't there a way to subscribe to general clipboard events, handle them in the main window's event loop by caching the content, and only work with that cache in getClipboard?

Thanks for the review!

There's no such thing as "general clipboard events", you can only get these events if you request them. We could either request the contents on every call to processEvents (overhead), and have the function be semi-asynchronous (getClipboard will request that the cache is updated and return the cache, but not the new clipboard contents). The problem is that if the contents are requested too often, then you'll lock up whichever program owns the clipboard. (So if you're doing a test program at 5000FPS, X11 will probably die.)

The current implementation adds a lot of redundant code and one issue I can see is that we have to take a lot of attention not to forget event stuff that's present in the "main" event loop.

Yes! A solution is to modify WindowImplX11::processEvents() and give it the possibility to process all the events until a specific event. Or something like that. I'm new to contributing to SFML, so I didn't want to move too much code around.

36

General discussions / Re: Clipboard support on Linux: A few hiccups.

« on: October 05, 2014, 09:00:00 pm »

Okay, I pushed my work to Git: https://github.com/Mischa-Alff/SFML/tree/feature/clipboard

Any criticism is appreciated.
Any testing is appreciated.
Be sure to checkout the feature/clipboard branch!

Cheers!

37

General discussions / Re: Clipboard support on Linux: A few hiccups.

« on: October 05, 2014, 08:42:29 pm »

Woo! It's working! It's finally working!

I'm just cleaning up my code and commenting it all, then I'll put it up on GitHub for testing.

38

General discussions / Re: Clipboard support on Linux: A few hiccups.

« on: October 04, 2014, 09:56:34 pm »

After much more research and after a good night's sleep:

• You don't need to own the clipboard to request data. (You shouldn't own the clipboard to request data, since you'd be requesting the data from the owner: yourself)
• You need to own the clipboard to set its contents.
• If the owner of the clipboard no longer exists, the contents of the clipboard disappear.
• Ownership of the clipboard should be kept until someone else requests it. Then the burden of Mighty Clipboard Data Holder is lifted.
  

I'm pretty sure whoever designed this stuff was way over Ballmer Peak.

I'll add more as I go.

39

General discussions / Re: Clipboard support on Linux: A few hiccups.

« on: October 03, 2014, 07:17:18 pm »

No suggestion, but a question: Will this be different/easier with XCB?

This is exactly the same procedure with XCB as with Xlib. The code only changes in a few places.

40

General discussions / Clipboard support on Linux: A few hiccups.

« on: October 03, 2014, 06:55:38 pm »

Hello all!

I've been spending the last few hours determined to get clipboard support working on Linux. You can check my progress here: https://github.com/Mischa-Alff/SFML/feature/clipboard
(NOTE: I won't push my current progress with support for X11 until it's finished. There's no point in making tiny little commits for every two lines of code)

I'm not 100% familiar with everything, so this is essentially all to the extend of my understanding. I might be wrong. God, I hope I'm wrong, but using X is a land of sadomasochism, and if I were wrong, it wouldn't be sadomasochism anymore.

The problems

• To receive the clipboard's contents, you must request ownership of the clipboard, request its contents, and then wait for an event containing the property that points to the contents of the clipboard. (This is apparently to prevent uselessly sending data around all the time)
• Once you've obtained ownership of the clipboard, you need to store its contents and send them to the next client who requests the data, until someone else requests ownership. (According to ICCCM sec. 2.6.1.3, you must request ownership to request contents, but not everyone follows ICCCM)

The potential solutions

Obviously, the only solution to the second one is to stick the selection sending code in the sf::WindowImplX11::processEvent function.

The solution to the first one is slightly more complex: Most software waits for a selection_notify_event in the getClipboard function, therefore driving the CPU up to 100% and sending all possible events to the event handler until it reaches a selection_*_event, then processing that event and returning the data sent in the event. The problem with this method is that it will completely block execution until it gets to the event it wants, which might be never.

References:

• ICCCM sec. 2.6.1.3: http://tronche.com/gui/x/icccm/sec-2.html#s-2.6.1.3
• How GLFW does it (Look for "selection" and "clipboard"): https://github.com/glfw/glfw/blob/master/src/x11_window.c

I'm looking for recommendations as to how I should proceed on this, what would be best for the API, and what would be best for the codebase.

Please don't reply with your ideal vision of how the clipboard API should be, without any real advice. I'm trying to solve a problem that has been plaguing me for hours, and I would like a constructive discussion on how this could be solved.

Other than that, any help is appreciated and much needed. SFML needs clipboard support.
Thanks!

41

Feature requests / Re: Clipboard and open with default application support

« on: September 08, 2014, 03:21:51 am »

For reference, Aster (Mischa-Alff) was working on clipboard support. His repository is here.

I am indeed working on clipboard support. The link is here, rather. Win32 support is already implemented. Linux is a bit more complicated and I'd like to do it right instead of having some hacked together code. (By "a bit", I mean "Oh God my eyes are bleeding why did I ever commit to doing this?!")

We could handle all the Linux cut buffers/clipboard/selections etc, but honestly, it's not worth it. I'm settling on using X11 selections (or whatever they're called, it's late) because they work pretty much everywhere, and that's what everyone else uses.

I'd be a bit more enthusiastic about Linux support, but my ArchLinux drive died (after ten years of service), and I'm waiting for a new SSD to get delivered to move back to using Arch again. For what I've looked at so far, it might be worth having a clipboard event that's only handled internally, but I'll have to see how I should work with that.

The API is:

• sf::String sf::Window::getClipboard();
• void sf::Window::setClipboard(const sf::String&);

There's an example in examples/clipboard in case you want to test it out.

Also, on handling multiple MIME types, zsbzsb suggested we overload the function in sf::RenderWindow for image support. I'm still hesitant about this. If you want to use multiple MIME types in the clipboard, chances are what SFML will provide isn't enough, and you'll end up extending it yourself anyways.

Cheers.

42

Graphics / Re: Blocky font rendering

« on: September 08, 2014, 03:12:08 am »

Thanks for the clarifications.

The drive I had Arch on was really old and eventually gave up, so I've ordered an SSD and I guess I'll just wait for that to arrive to resume my Linux activities.

Cheers

43

Graphics / Re: Blocky font rendering

« on: September 08, 2014, 12:45:28 am »

Little known fact: VirtualBox has abysmal guest 3D (OpenGL included) support at the moment. I managed to get it working with an SVN build of the guest additions not too long ago on Arch Linux, but I assume that they aren't available that easily on Ubuntu. It becomes broken and gets fixed in their SVN revisions more often than the weather changes, so I wouldn't necessarily call a test in VirtualBox a valid one.

Yeah, I had to compile the guest modules from source to get OpenGL working, and I'm only using Ubuntu because I'd assume VirtualBox would have better support for it.

But my question remains: why would text display in the OpenGL example and not in the code I pasted?

44

Graphics / Re: Blocky font rendering

« on: September 07, 2014, 11:23:51 pm »

Can you try the master branch? Can you also try to create the window before doing anything else?

The same code with the master branch segfaults with backtrace:

Code: [Select]

Program received signal SIGSEGV, Segmentation fault.
0xb7cb53e9 in ___printf_fp (fp=fp@entry=0xbfffea90, info=0xbfffe654, args=args@entry=0xbfffe630) at printf_fp.c:1250
1250 printf_fp.c: No such file or directory.
(gdb) bt
#0  0xb7cb53e9 in ___printf_fp (fp=fp@entry=0xbfffea90, info=0xbfffe654, args=args@entry=0xbfffe630) at printf_fp.c:1250
#1  0xb7caf07f in _IO_vfprintf_internal (s=s@entry=0xbfffea90, format=<optimized out>, format@entry=0xb7560e4a "%.1f Chromium %s", ap=<optimized out>, ap@entry=0xbfffeb68 "") at vfprintf.c:1660
#2  0xb7cd18d2 in __IO_vsprintf (string=string@entry=0x2c <error: Cannot access memory at address 0x2c>, format=format@entry=0xb7560e4a "%.1f Chromium %s", args=args@entry=0xbfffeb68 "")
    at iovsprintf.c:42
#3  0xb7cb828f in __sprintf (s=0x2c <error: Cannot access memory at address 0x2c>, format=0xb7560e4a "%.1f Chromium %s") at sprintf.c:32
#4  0xb73fcf49 in packspu_GetString () from /usr/lib/i386-linux-gnu/VBoxOGLpackspu.so
#5  0xb76c3253 in cr_glGetString () from /usr/lib/i386-linux-gnu/dri/vboxvideo_dri.so
#6  0xb7f60d01 in sf::priv::GlContext::initialize (this=0x804e0d0) at /tmp/SFML/src/SFML/Window/GlContext.cpp:279
#7  0xb7f607fe in sf::priv::GlContext::globalInit () at /tmp/SFML/src/SFML/Window/GlContext.cpp:126
#8  0xb7f61bd7 in sf::GlResource::GlResource (this=0xbfffee00) at /tmp/SFML/src/SFML/Window/GlResource.cpp:53
#9  0xb7f657b4 in sf::Window::Window (this=0xbfffee00) at /tmp/SFML/src/SFML/Window/Window.cpp:48
#10 0xb7fb679e in sf::RenderWindow::RenderWindow (this=0xbfffee00, mode=..., title=..., style=7, settings=...) at /tmp/SFML/src/SFML/Graphics/RenderWindow.cpp:42
#11 0x08049f8a in main () at test.cpp:17


Moving the window creation to the top of the function doesn't change anything.

45

Graphics / Re: Blocky font rendering

« on: September 06, 2014, 04:47:33 pm »

Just tried the code in Ubuntu 14.04( not virtual machine) and everything render fine. Using the same font from OpenGL example.

Hm.. this is weird.. Did you try the feature/xcb branch? Why would both work outside of a VM, but only one would work within a VM?