Java-Gaming.org Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (773)
Games in Android Showcase (230)
games submitted by our members
Games in WIP (856)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 [2]
  ignore  |  Print  
  Making GUIs  (Read 29436 times)
0 Members and 1 Guest are viewing this topic.
Offline basil_

« JGO Bitwise Duke »


Medals: 418
Exp: 13 years



« Reply #30 - Posted 2015-03-02 21:37:53 »

the only thing that sun did not do well is to give us proper control over polling and flushing queues - which is done by the EDT for us.

would be nice to remove EDT all together and just (re)implement it's purpose wherever we'd like .. but then, if most people cannot use the EDT properly right now, how many will be able to write or use a custom implementation ? Wink

good news if they dropped runAndWait() from javaFX. means they're using their own framework properly. nothing stops your from implementing your own runAndWait() method, with a Lock and Condition Wink
Offline nsigma
« Reply #31 - Posted 2015-03-02 23:05:49 »

Modal dialogs do not cause a new Thread to spawn. They create a new Event Queue and Event pump, right on top of the current queue/pump. Think of it as recursion. A stack of queues and pumps, where only the top of the stack is active.

hmm .. OK, that's me misreading some ambiguous JavaDoc  Roll Eyes - to me, that doesn't count as "block the execution of the current thread".  Has that always been the case?  Vague recollection of seeing new event threads spawned from dialogs in the long distant past, but guess that might be the other reason you mention.

Still doesn't mean I like this (fake) blocking behaviour, but it's a bit better than I assumed.

the only thing that sun did not do well is to give us proper control over polling and flushing queues - which is done by the EDT for us.

What exactly do you want by "proper control" above what EventQueue or a custom subclass gives you (assuming you can re-appropriate the dispatch thread)?  Not that I don't agree with all of your second sentence!  Wink

Praxis LIVE - hybrid visual IDE for (live) creative coding
Offline CommanderKeith
« Reply #32 - Posted 2015-03-03 06:02:42 »

As that article said:
Quote
...processes (threads) and monitors (locks) are duals. Well, yes, it's true. In some sense we are using the event thread to implement a global lock. We could invert things, and create a global lock that is equivalent to the event queue.

If there was more flexibility in the Swing API's threading model then I think it would be a better library which could be used in directly-rendered games without forcing us to do everything on the EDT. The EDT is an unnecessary and annoying aspect of the API which could have easily been done differently, such as using locks or letting the developer use their own game loop thread. However, the Swing API has no flexibility to do this.

As I said, I can't see why the Swing engineers couldn't:
  • Expose a hook to let us see the OS event queue in our game loop thread if we want so we can take the events we want to consume and make game logic updates
  • Let us call an update method on the Swing components with any relevant events for them given as an argument which would happen in our game loop thread,
  • Let us call paint on the Swing components from our game loop thread and repeat.

@KevinWorkman and @PrinceC. While I appreciate both of your input on the forum since your posts are often very insightful and entertaining, in this case it's disappointing to see you repeatedly dismiss me as 'not really understanding how threading works' while failing to answer my question, which is: show me how you can make Swing render in your own thread without the event dispatch thread (EDT).

If you can do it as easily as you say, I'd be very impressed. The code would be an important contribution to the community since the Swing library is well designed in general, we're all familiar with the API and it comes included in the jdk.

I've tried to make Swing run in a direct rendering game not rendered on the EDT, and so have many others including the swing-gl programmers, but we all failed in one way or another. The swing-gl programmers only make it work using reflection hacks to overcome the lack of flexibility in the Swing API.
In my multiplayer networked game SydneyEngine (http://www.java-gaming.org/topics/multiplayer-top-down-view-shooter/18019/view.html), I use Swing menus but was forced to use invokeAndWait(renderSwingMenus) to draw the user interface on the EDT, since the swing API forces it to be so.

the only thing that sun did not do well is to give us proper control over polling and flushing queues - which is done by the EDT for us.

What exactly do you want by "proper control" above what EventQueue or a custom subclass gives you (assuming you can re-appropriate the dispatch thread)?  Not that I don't agree with all of your second sentence!  Wink
I agree with basil. I would like to use the swing GUI without having to change my threading model, which I think is completely unnecessary for a GUI to impose. Imagine if every library insisted that its code run on a specific thread. There'd be invokeAndWait equivalents every time I tried to use any libraries' code, making quite a mess.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline princec

« JGO Spiffy Duke »


Medals: 1059
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #33 - Posted 2015-03-03 08:22:54 »

@KevinWorkman and @PrinceC. While I appreciate both of your input on the forum since your posts are often very insightful and entertaining, in this case it's disappointing to see you repeatedly dismiss me as 'not really understanding how threading works' while failing to answer my question, which is: show me how you can make Swing render in your own thread without the event dispatch thread (EDT).
Dude, your whole response there continues to show me that you do not understand the problem you are trying to solve at all, and you really need to do some research (written by lots of other people) rather than insist we sit here and type lengthy multi-page treatises about it all.

But as a shortcut:

What you want to do with Swing is called Active Rendering. The nub of the gist is that you need to:
a) Paint in your main loop thread
b) Take any and all input events from the EDT and pass them in a thread safe manner to your main loop

or you could potentially just hop aboard the EDT and start running your game loop from there but I suspect trouble lies that way.

Useful link http://docs.oracle.com/javase/tutorial/extra/fullscreen/rendering.html

Your main issue is that Swing is designed as a passive event-loop driven system and it looks like you want to make a game which is almost always done in a totally different way. Games generally repaint the screen at a fixed rate or as fast as they can and do everything - direct input, logic, rendering - in a single thread "main loop", occasionally doing clever stuff with other threads but that tends to be somewhat advanced. They've hacked a bit at Swing to make it possible but it's not a smooth ride. If you want my advice, just stay away from Swing if you're writing a realtime game of any sort.

All this stuff about blocking, multiple EDTs, event queues, OS hooks, etc - all red herrings, none of you need it or even need to know about it which is why it's so well buried. Move along, nothing to see.

Cas Smiley

Offline basil_

« JGO Bitwise Duke »


Medals: 418
Exp: 13 years



« Reply #34 - Posted 2015-03-03 10:07:55 »

the only thing that sun did not do well is to give us proper control over polling and flushing queues - which is done by the EDT for us.

What exactly do you want by "proper control" above what EventQueue or a custom subclass gives you (assuming you can re-appropriate the dispatch thread)?  Not that I don't agree with all of your second sentence!  Wink

pretty much what CommanderKeith says :

  • Expose a hook to let us see the OS event queue in our game loop thread if we want so we can take the events we want to consume and make game logic updates
  • Let us call an update method on the Swing components with any relevant events for them given as an argument which would happen in our game loop thread,
  • Let us call paint on the Swing components from our game loop thread and repeat.

What you want to do with Swing is called Active Rendering. The nub of the gist is that you need to:
a) Paint in your main loop thread
b) Take any and all input events from the EDT and pass them in a thread safe manner to your main loop

or you could potentially just hop aboard the EDT and start running your game loop from there but I suspect trouble lies that way.

ja, that works. but how could it be possible to build a lookandfeel implementation drawing/interacting with a arbitrary game loop ? the more i think about it the more i look on the CGlib. i mean things are called from EDT (like paint() as a result of a OS event) which i cannot intercept without buttpain.

Offline princec

« JGO Spiffy Duke »


Medals: 1059
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #35 - Posted 2015-03-03 10:27:27 »

When you switch to active rendering you're in control of paint() not the EDT.

Cas Smiley

Offline basil_

« JGO Bitwise Duke »


Medals: 418
Exp: 13 years



« Reply #36 - Posted 2015-03-03 10:55:29 »

 Shocked setting a proper BufferStrategy makes EDT not call paint() on a component and allows painting the whole component-tree in custom thread ?

i know how to use graphics2D speedy on a canvas - but this about GUI's. how could we take swing and all it's widgets and whatnots and use it with ... libGDX or something ? i mean, without setting everything to setIgnoreRepaint(true) .. or overwritting all paint methods .. or writing a whole java.awt.Toolkit implementation.

just thinking, building a LnF is pretty simple, having it run a few GL draw-calls wouldn't be too much to ask.
Offline nsigma
« Reply #37 - Posted 2015-03-03 12:05:33 »

pretty much what CommanderKeith says :

  • Expose a hook to let us see the OS event queue in our game loop thread if we want so we can take the events we want to consume and make game logic updates
  • Let us call an update method on the Swing components with any relevant events for them given as an argument which would happen in our game loop thread,
  • Let us call paint on the Swing components from our game loop thread and repeat.

You can do all that already!  To paint, you could use active rendering, or if you're running your game loop in the EDT you could control the default Swing paint mechanism.  For the other two, use Toolkit.getSystemEventQueue() to get access to the queue.  If you're running your game loop in the EDT, just pull events and dispatch (see component.dispatchEvent()).  Otherwise, push your own EventQueue implementation on top of the existing and override EventQueue.dispatchEvent() to filter / pass to your game thread.  The latter might have an issue if anything was using EventQueue.isDispatchThread() though.

Shocked setting a proper BufferStrategy makes EDT not call paint() on a component and allows painting the whole component-tree in custom thread ?

Not exactly!  Read the link @princec gave, in particular the second point under programming tips -

Quote
Use the setIgnoreRepaint method on your application window and components to turn off all paint events dispatched from the operating system completely, since these may be called during inappropriate times, or worse, end up calling paint, which can lead to race conditions between the AWT event thread and your rendering loop.

Praxis LIVE - hybrid visual IDE for (live) creative coding
Offline KevinWorkman

« JGO Plugged Duke »


Medals: 287
Projects: 12
Exp: 12 years


HappyCoding.io - Coding Tutorials!


« Reply #38 - Posted 2015-03-03 14:41:51 »

If there was more flexibility in the Swing API's threading model then I think it would be a better library which could be used in directly-rendered games without forcing us to do everything on the EDT.

As I've already said, you don't have to do everything on the EDT. The flexibility you're complaining about not having? You have it.

The EDT is an unnecessary and annoying aspect of the API which could have easily been done differently, such as using locks or letting the developer use their own game loop thread. However, the Swing API has no flexibility to do this.

Sorry, but I'll take a single-threaded approach over dealing with locks and threads any day. The EDT approach is not just a Swing thing- like I already pointed out, most modern GUI libraries are single-threaded. Anything more than that is overkill for 99% of GUI applications. But if you really want that flexibility- you already have it.

As I said, I can't see why the Swing engineers couldn't:
  • Expose a hook to let us see the OS event queue in our game loop thread if we want so we can take the events we want to consume and make game logic updates

You can.

  • Let us call an update method on the Swing components with any relevant events for them given as an argument which would happen in our game loop thread,

You can.

  • Let us call paint on the Swing components from our game loop thread and repeat.

You can.

@KevinWorkman and @PrinceC. While I appreciate both of your input on the forum since your posts are often very insightful and entertaining, in this case it's disappointing to see you repeatedly dismiss me as 'not really understanding how threading works' while failing to answer my question, which is: show me how you can make Swing render in your own thread without the event dispatch thread (EDT).

I'm not trying to be condescending, but do you see how your attitude in this paragraph might suggest that you're in a little over your head with this topic? A quick google of "Swing active rendering" would get you started. Have you done that? Have you posted any code that shows what you're talking about? Nope. You've instead complained about things that aren't true and have demanded that we post the code for you.

If you can do it as easily as you say, I'd be very impressed. The code would be an important contribution to the community since the Swing library is well designed in general, we're all familiar with the API and it comes included in the jdk.

This is the first result for googling "java swing active rendering": http://docs.oracle.com/javase/tutorial/extra/fullscreen/rendering.html

And here's a really dumb program that follows the bullet points at the bottom of that link to perform active rendering in Swing, off the EDT:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
30  
31  
32  
33  
34  
35  
36  
37  
38  
39  
40  
41  
42  
43  
44  
45  
46  
47  
48  
49  
50  
51  
52  
53  
54  
55  
56  
57  
58  
59  
60  
61  
62  
63  
64  
65  
66  
67  
68  
69  
70  
71  
72  
73  
74  
75  
76  
77  
78  
79  
80  
import java.awt.Color;
import java.awt.Graphics;

import javax.swing.JFrame;
import javax.swing.JPanel;

/**
 * This is an example that shows the very basics of active rendering in Swing.
 * Note that this code is dumb, does not use double-buffering (hence the flickering),
 * and should not be used by anybody in a real program.
 *
 * If you think you have to do active rendering in Swing, you're probably wrong.
 *
 */

public class Main {

   public static void main(String... args) {


      JFrame frame = new JFrame("Active Rendering Test");
      frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);


      final  JPanel myPanel = new JPanel();
     
      //no more rendering on EDT
      myPanel.setIgnoreRepaint(true);
     
      //background will never be drawn by Swing, thanks to above line
      myPanel.setBackground(Color.RED);
     
      frame.add(myPanel);

      frame.setSize(500, 500);
      frame.setVisible(true);

      Thread renderThread = new Thread(){
         public void run(){
           
            double ballX = 100;
            double ballY = 100;
           
            double speed = .1;
           
            double deltaX = speed;
            double deltaY = speed;
           
            while(true){

               if(ballX > myPanel.getWidth()){
                  deltaX = -speed;
               }
               if(ballX < 0){
                  deltaX = speed;
               }
               
               if(ballY > myPanel.getHeight()){
                  deltaY = -speed;
               }
               
               if(ballY < 0){
                  deltaY = speed;
               }
               
               ballX += deltaX;
               ballY += deltaY;
               
               Graphics g = myPanel.getGraphics();
               g.setColor(Color.WHITE);
               g.fillRect(0, 0, myPanel.getWidth(), myPanel.getHeight());
               g.setColor(Color.BLACK);
               g.drawRect((int)ballX, (int)ballY, 100, 100);
               g.dispose();
            }
         }
      };

      renderThread.start();
   }
}



I've tried to make Swing run in a direct rendering game not rendered on the EDT, and so have many others including the swing-gl programmers, but we all failed in one way or another. The swing-gl programmers only make it work using reflection hacks to overcome the lack of flexibility in the Swing API.

Please see above. If you still have a question, please post your own code in the form of an MCVE.

In my multiplayer networked game SydneyEngine (http://www.java-gaming.org/topics/multiplayer-top-down-view-shooter/18019/view.html), I use Swing menus but was forced to use invokeAndWait(renderSwingMenus) to draw the user interface on the EDT, since the swing API forces it to be so.

Again, not trying to be condescending- but it sounds like you really need to overhaul your design. That's why we're saying you might not understand threading as well as you think you do, because you really seem to be misusing it.

I agree with basil. I would like to use the swing GUI without having to change my threading model, which I think is completely unnecessary for a GUI to impose. Imagine if every library insisted that its code run on a specific thread. There'd be invokeAndWait equivalents every time I tried to use any libraries' code, making quite a mess.

Like I've said several times now, this is not just a Swing thing. Almost every GUI library (including OpenGL, Android, JavaFX, libGDX, and JMonkeyEngine) uses this model. I promise that the people behind these libraries have put more thought into it than you or I. The fact that you think this is ridiculous is why we're suggesting that maybe you simply don't understand the model. We aren't trying to be condescending- we're trying to help you understand.

Edit: And like Cas says, none of this really matters. If you really think you need to go through all of this rigmarole with active rendering and threading in Swing: you're either wrong, or you should be using a different library that handles it for you.

HappyCoding.io - Coding Tutorials!
Happy Coding forum - Come say hello!
Offline Riven
Administrator

« JGO Overlord »


Medals: 1356
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #39 - Posted 2015-03-03 18:18:48 »

Nuff of this. We all have our ill-informed moments. No need to 'gang up' on our beloved Keith. I'm sure lots of people found new information in this thread about the inner workings of Swing - we should focus on sharing such information instead of telling eachother how ill-informed we are, over and over and over. We don't need N similar corrections from N people quoting the same statement. It gets old rather quickly.

I'm not saying this as a moderator - just as a slightly annoyed innocent bystander.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings!
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline KevinWorkman

« JGO Plugged Duke »


Medals: 287
Projects: 12
Exp: 12 years


HappyCoding.io - Coding Tutorials!


« Reply #40 - Posted 2015-03-03 18:26:55 »

Nuff of this. We all have our ill-informed moments. No need to 'gang up' on our beloved Keith. I'm sure lots of people found new information in this thread about the inner workings of Swing - we should focus on sharing such information instead of telling eachother how ill-informed we are, over and over and over. It gets old rather quickly.

I can mostly agree with you. And like I said, I'm not trying to be condescending. But in this case, his statements were incorrect. I'm not trying to be rude or start a flamewar; I'm trying to explain that the things he wants already exist in Swing. I even wrote a little program in the name of sharing information, and I will happily take a look at any code he has that's confusing him.

I don't think anybody is ganging up on The Commander. But some of what he said does sound like a misunderstanding of how the model works, and we're trying to correct that.

If you have any suggestions on how to go about this more delicately, I'm definitely all ears and will edit my last post as you see fit. I'm treating this like a technical forum, so I understand that my responses can be a bit short. It's in the name of getting to the point, not in being condescending.

HappyCoding.io - Coding Tutorials!
Happy Coding forum - Come say hello!
Offline basil_

« JGO Bitwise Duke »


Medals: 418
Exp: 13 years



« Reply #41 - Posted 2015-03-03 18:51:20 »

i did learn alot from this tho' Smiley
Offline Cero
« Reply #42 - Posted 2015-03-04 01:49:27 »

If you have any suggestions on how to go about this more delicately, I'm definitely all ears and will edit my last post as you see fit. I'm treating this like a technical forum, so I understand that my responses can be a bit short. It's in the name of getting to the point, not in being condescending.
The "You can." answers seem passive aggressive to the max. Not even one line saying how you would ever do that. Doesnt seem very helpful - all you are doing is saying "you are wrong".

Thats like some would say "I wish there was a way to take water and break it down into hydrogen and oxygen gas" and your answer is "You can." instead of saying "well this can be accomplished via electrolysis which uses an electrolyte, electrodes and current."

Offline CommanderKeith
« Reply #43 - Posted 2015-03-04 03:40:44 »

And here's a really dumb program that follows the bullet points at the bottom of that link to perform active rendering in Swing, off the EDT:
1  
2  
3  
4  
5  
6  
               Graphics g = myPanel.getGraphics();
               g.setColor(Color.WHITE);
               g.fillRect(0, 0, myPanel.getWidth(), myPanel.getHeight());
               g.setColor(Color.BLACK);
               g.drawRect((int)ballX, (int)ballY, 100, 100);
               g.dispose();

I don't think that you understand the problem, which is to paint Swing components inside the game loop, not rendering inside an empty JPanel. There should be a swingComponent.paint(g) in there.

When you switch to active rendering you're in control of paint() not the EDT.
setIgnoreRepaint only stops the operating system (OS) events from calling paint, not internal changes to the menu. See the java docs:
Quote
Sets whether or not paint messages received from the operating system should be ignored. This does not affect paint events generated in software by the AWT, unless they are an immediate response to an OS-level paint message.
This is useful, for example, if running under full-screen mode and better performance is desired, or if page-flipping is used as the buffer strategy.
So for example, if the game logic calls setText(String) on an in-game GUI JLabel, then inside the JLabel.setText method repaint is called, which posts an even to the EventQueue, which will occur on the EDT even though setText was called from the game loop thread, conflicting with the painting of that button in my game loop thread.
Stopping this is difficult, as basil said it requires 'interception' of the event on the EDT which is not easy. I thought it was impossible since no-one has shown how it is done without reflection hacks, but I'm open to being proved wrong. nsigma is the only person who has offered reasonable advice, and even then I wonder if it's possible.

You can do all that already!  To paint, you could use active rendering, or if you're running your game loop in the EDT you could control the default Swing paint mechanism.  For the other two, use Toolkit.getSystemEventQueue() to get access to the queue.  If you're running your game loop in the EDT, just pull events and dispatch (see component.dispatchEvent()).  Otherwise, push your own EventQueue implementation on top of the existing and override EventQueue.dispatchEvent() to filter / pass to your game thread.  The latter might have an issue if anything was using EventQueue.isDispatchThread() though.

nsigma at least understands the problem and offers some directions to the solution. The run-your-game-loop-on-the-EDT solution is obvious and isn't the solution I'm after which is painting the GUI in my own thread.
How do you push your own EventQueue? I note that there is Toolkit.getEventQueue but no Toolkit.setEventQueue()?
I would like to see your EDT-event interception idea work. As I said, no-one has demonstrated this being done that I have ever found.

Nuff of this. We all have our ill-informed moments. No need to 'gang up' on our beloved Keith. I'm sure lots of people found new information in this thread about the inner workings of Swing - we should focus on sharing such information instead of telling eachother how ill-informed we are, over and over and over. We don't need N similar corrections from N people quoting the same statement. It gets old rather quickly.
Thanks, it's nice to be beloved! I'll be the first person to admit that I'm wrong, but so far it seems that people either don't understand the problem or dismiss it as not being a problem.

I would like to treat the GUI like everything else in a game: with an update and a paint method. I thought that is what we would all want Huh

Quote
Like I've said several times now, this is not just a Swing thing. Almost every GUI library (including OpenGL, Android, JavaFX, libGDX, and JMonkeyEngine) uses this model. I promise that the people behind these libraries have put more thought into it than you or I.
If every GUI library has an EDT like Swing, I'm surprised. I think it's a design deficiency because it's inflexible. According to the principal of loose-coupling, Swing's event system, painting and logic should be separable, but clearly they aren't.

Quote
Edit: And like Cas says, none of this really matters. If you really think you need to go through all of this rigmarole with active rendering and threading in Swing: you're either wrong, or you should be using a different library that handles it for you.
On the whole I like the swing libary and it's what I know. If I could re-use it in my games I would. But the way it enforces everything to be done on the EDT is quite irritating. I will try libgdx's scene2d.ui, nifty or TWL for my next projects.

That tutorial guide gives no working examples, and even worse, it seems to indicate that active-rendering swing components from a non-EDT game loop thread in a thread safe way is impossible, since it says:
Quote
Don't put drawing code in the paint routine. You may never know when that routine may get called! Instead, use another method name, such as render(Graphics g), which can be called from the paint method when operating in windowed mode, or alternately called with its own graphics from the rendering loop.
It seems to indicate that a swing component's paint method can be called at any time from the EDT (with or without setIgnoreRepaint) and therefore you can't truly paint swing components in your own game loop thread.

By the way, it's great to be part of a forum where we can debate interesting topics like this.

Offline nsigma
« Reply #44 - Posted 2015-03-04 09:12:34 »

nsigma at least understands the problem and offers some directions to the solution. The run-your-game-loop-on-the-EDT solution is obvious and isn't the solution I'm after which is painting the GUI in my own thread.

And I say this in the friendliest way (eyeballs @Riven Wink ) - What's so damn special about your own thread?  Do you complain that main() doesn't run in your own thread?  Now, I'm not 100% sure this is the way to go, or that AWT wouldn't kick up a fuss about it, but it would be the simplest way - just make sure to manually drain and dispatch the event queue!

1  
2  
3  
4  
5  
6  
7  
public static void main (final String[] args) {
  EventQueue.invokeLater(new Runnable() {
    public void run() {
      actualMain(args);
    }
  }
}


If you're stuck with using another thread, I have doubts, as you do, about active rendering from another thread while the EDT is still processing events - not just on the paint() thing, but also because models aren't thread-safe.  So, custom queue ...

How do you push your own EventQueue? I note that there is Toolkit.getEventQueue but no Toolkit.setEventQueue()?
I would like to see your EDT-event interception idea work. As I said, no-one has demonstrated this being done that I have ever found.

Try some Google-fu on "extends EventQueue"!  Cheesy  There are lots of projects using event queue interception for various reasons - the one I'm most familiar with is in NetBeans because I work with the RCP a lot (this doesn't re-dispatch to another thread, but times and warns on long running events)

The method you're looking for is called push(), but it's on EventQueue itself.  You don't replace the Toolkit queue, you push another on top of it.

Praxis LIVE - hybrid visual IDE for (live) creative coding
Offline basil_

« JGO Bitwise Duke »


Medals: 418
Exp: 13 years



« Reply #45 - Posted 2015-03-04 09:30:05 »

settting a new event-queue :
Toolkit.getDefaultToolkit().getSystemEventQueue().push(new EventQueue());
.
Offline KevinWorkman

« JGO Plugged Duke »


Medals: 287
Projects: 12
Exp: 12 years


HappyCoding.io - Coding Tutorials!


« Reply #46 - Posted 2015-03-04 14:31:17 »

The "You can." answers seem passive aggressive to the max. Not even one line saying how you would ever do that. Doesnt seem very helpful - all you are doing is saying "you are wrong".

Thats like some would say "I wish there was a way to take water and break it down into hydrogen and oxygen gas" and your answer is "You can." instead of saying "well this can be accomplished via electrolysis which uses an electrolyte, electrodes and current."

Fair enough. I wasn't trying to be passive aggressive, but the onus usually isn't on us to prove every little misunderstanding wrong. When we get people making posts like "teh jav is suck, C++ is faster and you can use it for games" - we usually just tell them that they're wrong and leave them to their own research, right? If they have specific code showing specific benchmarks we can talk about that, but generally we just tell them "you're wrong, here's some links explaining why, now if you have some code, please post it."

And that's exactly what I did here. I'm not saying CK is a novice or a troll, in fact I quite like the dude, but I feel like I'm being scolded for telling somebody they're technically incorrect- on a technical forum.

Can we take another look at the conversation from my perspective?

Post 11: CK: Everything must be done on the event dispatch thread rather than your game loop thread, which is quite irritating.
Post 13: CK: I don't see why painting, logic and event processing should be restricted to the same thread. It seems like it wasn't thought out very well by the Sun swing engineers.
Post 16: Me: Here's a link to an explanation about why the EDT works the way it does.
Post 18: CK: That way Swing components could be used in a 'direct-rendering' game loop thread, rather than the current requirement where everything to do with them must be done on the EDT.
Post 21: Me: You can.
Post 22: CK: I've never heard of anyone doing it, because I presume that it's impossible.
Post 25: Me: You can absolutely do that.
Post 32: CK: Show me how you can make Swing render in your own thread without the event dispatch thread (EDT).
Post 38: Me: You can, and here's some code.
Post 39: Riven: don't gang up on CK

If it were anybody else, we would have required code to support the claims. But instead, the onus is on us to discount what appears to be a simple misunderstanding of Swing's model. That seems backwards. It's like me making a post that says libGDX sucks because you can't render images- and then requiring other people to post code that proves me wrong.

Anyway, I was going to make a longer post explaining each of my "you can" statements with another code example, but basil_ and nsigma have already covered the basics- and I don't want to appear to be ganging up on anybody.

I hope there are no hard feelings, and I apologize if I came off as passive aggressive or condescending. That was not my intention. Chit-Chat Monster, here I come.

HappyCoding.io - Coding Tutorials!
Happy Coding forum - Come say hello!
Offline CommanderKeith
« Reply #47 - Posted 2015-03-04 14:44:57 »

The method you're looking for is called push(), but it's on EventQueue itself.  You don't replace the Toolkit queue, you push another on top of it.
Thank you, I'll try that and report back. It certainly looks like the solution I'm after, which is great.

nsigma at least understands the problem and offers some directions to the solution. The run-your-game-loop-on-the-EDT solution is obvious and isn't the solution I'm after which is painting the GUI in my own thread.
And I say this in the friendliest way (eyeballs @Riven Wink ) - What's so damn special about your own thread?  Do you complain that main() doesn't run in your own thread?  Now, I'm not 100% sure this is the way to go, or that AWT wouldn't kick up a fuss about it, but it would be the simplest way - just make sure to manually drain and dispatch the event queue!
1  
2  
3  
4  
5  
6  
7  
public static void main (final String[] args) {
  EventQueue.invokeLater(new Runnable() {
    public void run() {
      actualMain(args);
    }
  }
}

There's nothing special about my main game loop thread. But what's so special about the GUI library? I just don't think that a GUI library needs to bundle a thread with itself and force me to do all event handling, painting and logic on it. I mean, what if the physics, lighting, AI and scripting also insisted on running all their code on their own threads? It'd be a nightmare. I don't see what's so special about a GUI when all it's supposed to do is update and paint like everything else  Huh

Quote
If you're stuck with using another thread, I have doubts, as you do, about active rendering from another thread while the EDT is still processing events - not just on the paint() thing, but also because models aren't thread-safe.  So, custom queue ...
It seems as though Swing model updates are also just events on the EventQueue, so I should be able to intercept them if EventQueue.push() works out.

By the way, I stumbled on this java.net forum thread which was written by the Swing dev's Scott Violet and Dmitri Trembovetski:
https://www.java.net/node/644028
Dmitri says that the context-switching from calling invokeLater is expensive in the last post. So perhaps there's also a performance reason why rendering from a single thread is a better idea.

Thanks for your advice nsigma, much appreciated.

Offline princec

« JGO Spiffy Duke »


Medals: 1059
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #48 - Posted 2015-03-04 14:54:23 »

There's nothing special about it. It's just designed primarily to be an OS-event-driven UI library for normal UIs, for which its design is perfectly optimal.

FWIW I've got my own UI library I use for making games UIs. It executes in the main loop, and renders in the main loop, and doesn't even use "events" (just a horribly complex load of state machines). As soon as I want to do anything asynchronous, I have to punt it out into another thread and I am only allowed to interact with my own UI in the main thread. It's a solution you'll end up with time and time again - it's best to accept that's the way it works.

At least with static import and lambda Runnables now it's nowhere near as fiddly and ugly as it used to look:
1  
invokeLater(()->{ setText("Finished!"); });


Cas Smiley

Offline CommanderKeith
« Reply #49 - Posted 2015-03-04 15:41:12 »

Fair enough. I wasn't trying to be passive aggressive, but the onus usually isn't on us to prove every little misunderstanding wrong. When we get people making posts like "teh jav is suck, C++ is faster and you can use it for games" - we usually just tell them that they're wrong and leave them to their own research, right? If they have specific code showing specific benchmarks we can talk about that, but generally we just tell them "you're wrong, here's some links explaining why, now if you have some code, please post it."

Thanks, and no hard feelings either. I think it's great that a solution might have been found. If I had to pay for all the experts who participated in this thread it would surely cost thousands!   Cool

But there was obviously a misunderstanding which is evident in the code you posted. You were talking about direct-rendering inside an empty JPanel which is pretty simple, there was no swingComponent.paint(Graphics2D) going on so there were no Swing GUI components (except the empty JPanel) being actively rendered. Whereas I was talking about drawing Swing components on top of the game graphics at 60Hz.

I thought this was obvious, and I also thought that you and PrinceC would only talk with such authority on the topic if you had actually achieved active rendering with Swing components painted on top of the game graphics without involving the EDT. Therefore I figured that sharing your secret and posting code would not be hard. But that's fine, it was just a misunderstanding about what 'direct rendering' meant. Next time I'll be more specific.

FWIW I've got my own UI library I use for making games UIs. It executes in the main loop, and renders in the main loop, and doesn't even use "events" (just a horribly complex load of state machines). As soon as I want to do anything asynchronous, I have to punt it out into another thread and I am only allowed to interact with my own UI in the main thread. It's a solution you'll end up with time and time again - it's best to accept that's the way it works.
I think your system is perfect, it's exactly what I would want in a GUI library too. No bundled EDT thread, and you probably have an update and paint method, with no locks since you do all the work in your own single thread. Swing should be able to be used like this, there was no need to tie the GUI component library to the EDT. Let the programmer manage his own threading problems. Yet for some reason you disagree with me  Huh

Offline KevinWorkman

« JGO Plugged Duke »


Medals: 287
Projects: 12
Exp: 12 years


HappyCoding.io - Coding Tutorials!


« Reply #50 - Posted 2015-03-04 16:05:58 »

I'm going to butt out of this one, but I'll just say that what you're talking about is still possible, if not as simple as the one-line change you might be hoping for.

I understand your requirement, and the code I posted was meant as a bare minimum. You'd still use that basic idea for the more complicated stuff you're talking about.

I will also say that trying to bend Swing this way is probably a horrible idea. I make my living as a Swing developer, so I absolutely feel your pain and desire for Swing to be easier to throw on top of other stuff.

I wonder if it's easier to use JavaFX that way?

HappyCoding.io - Coding Tutorials!
Happy Coding forum - Come say hello!
Offline princec

« JGO Spiffy Duke »


Medals: 1059
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #51 - Posted 2015-03-04 16:06:41 »

There is indeed a little confusion here as to what you were trying to do, which is now clearer. Basically hijacking Swing to render itself on top of some other scene maybe rendered by LWJGL, am I right? Which is indeed possible, though what you probably want to actually be doing is rendering the Swing UI to a BufferedImage and then blitting that on top of the GL scene. It's fiddly though and requires some fun with event queues as hinted back along... and at the end of the day you'll have a fugly Swing UI on top of your pretty game which sort of defeats the point :|

The libgdx UIs seem very capable - see Spine for an example of a UI made entirely in libgdx and rendered with OpenGL. No Swing involved!

Cas Smiley

Offline basil_

« JGO Bitwise Duke »


Medals: 418
Exp: 13 years



« Reply #52 - Posted 2015-03-04 16:42:48 »

back to the OP : can we use swing to create a GUI with libGDX ?
Offline Sabomoth

Junior Devvie


Medals: 4
Exp: 3 years



« Reply #53 - Posted 2015-03-04 23:06:54 »

Yes, but why?


There are libraries that can do it for you a hundred times more fancy.
Here is one i found a year ago or so, but haven't tried in a game yet
http://l33tlabs.org/
Offline basil_

« JGO Bitwise Duke »


Medals: 418
Exp: 13 years



« Reply #54 - Posted 2015-03-04 23:30:30 »

why not ? swing is pretty complete, mature and not too hard to use. works out of the box.

would be nice to not reinvent the wheel or bring in more 3rd party dependencies Smiley
Offline philfrei
« Reply #55 - Posted 2015-03-05 02:56:00 »

I wonder if it's easier to use JavaFX that way?

This isn't really an answer to KevinWorkman's question, I don't think. But it does involve using JavaFX on Android, and I thought it looked interesting. Has anyone else sized up this strategy for running JavaFX on Android?

https://bitbucket.org/javafxports/android/wiki/Home
https://blogs.oracle.com/jfxprg/entry/javafx_on_android

Maybe this isn't a total hijack. The subject line of this thread is "Making GUIs" after all.

music and music apps: http://adonax.com
Offline Nate

« JGO Bitwise Duke »


Medals: 167
Projects: 4
Exp: 14 years


Esoteric Software


« Reply #56 - Posted 2015-03-07 04:58:09 »

Sheesh, wth are you guys doing in this thread?

Pages: 1 [2]
  ignore  |  Print  
 
 

 
EgonOlsen (1850 views)
2018-06-10 19:43:48

EgonOlsen (1879 views)
2018-06-10 19:43:44

EgonOlsen (1244 views)
2018-06-10 19:43:20

DesertCoockie (1679 views)
2018-05-13 18:23:11

nelsongames (1344 views)
2018-04-24 18:15:36

nelsongames (1962 views)
2018-04-24 18:14:32

ivj94 (2735 views)
2018-03-24 14:47:39

ivj94 (1937 views)
2018-03-24 14:46:31

ivj94 (3028 views)
2018-03-24 14:43:53

Solater (1077 views)
2018-03-17 05:04:08
Deployment and Packaging
by mudlee
2018-08-22 18:09:50

Java Gaming Resources
by gouessej
2018-08-22 08:19:41

Deployment and Packaging
by gouessej
2018-08-22 08:04:08

Deployment and Packaging
by gouessej
2018-08-22 08:03:45

Deployment and Packaging
by philfrei
2018-08-20 02:33:38

Deployment and Packaging
by philfrei
2018-08-20 02:29:55

Deployment and Packaging
by philfrei
2018-08-19 23:56:20

Deployment and Packaging
by philfrei
2018-08-19 23:54:46
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!