Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Page 2 of 2 FirstFirst 12
Results 11 to 16 of 16

Thread: rotating cube only rotates when window resized

  1. #11
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948
    if someone googles something, it shows clearly that he is interested in that topic.
    The whole point of that Google link is that the person wasn't necessarily Googling about XLib. They were Googling about Linux OpenGL programming; it just so happened that the first link talked about XLib.

    See the difference? Someone who has no idea about what XLib even is having it given to them. So you can't say that the page being high on Google means that people are "interested in" XLib; they're just having it shoved into their faces.

    when i look at the bottom of the page,
    it seems that it has received more good than bad ratings.
    And if the ratings of random users were indicative of quality, this might mean something.

    thats completely wrong. even if you program just in plain c, there are some things that you should know, even when
    you don't have to deal with them directly.
    C has been accused of many things. Being a "good abstraction" is not one of them. But then, that's not C's purpose and it never has been. It's purpose is to be a higher-level assembly, and that necessitates not being a "good abstraction" over assembly. It's leaky by design.

    Also, a lot of those things you mention are not something you "need" to know. They're useful, but hardly mandatory for being able to use the language. I certainly don't waste any thought on the memory layout of data structures unless I'm trying to match std140 in OpenGL or a file format or something.

    Qt by contrast is a good abstraction over platform-specific windowing systems. You can be a skilled Qt user without having any knowledge of how the underlying platform-specific windowing system works. You can't always ignore platform-specifics, but you can in the vast majority of your code.

    on linux, you may get
    exactly the same pointer in return
    No you don't. You sometimes do if the memory allocator can expand the memory of your allocation in-situ. If there is not enough room to do so in that allocation block, you will get a new pointer.

  2. #12
    Advanced Member Frequent Contributor
    Join Date
    Aug 2004
    Location
    munich, germany
    Posts
    659
    i dont see any difference between "you *may* get the same pointer" and "you *sometimes* get the same pointer"

    maybe some native english speaker can clarify if "you may get the same pointer" means "you always get the same pointer".

  3. #13
    Member Regular Contributor
    Join Date
    Jun 2013
    Posts
    498
    Quote Originally Posted by Alfonse Reinheart View Post
    Um, why not? As long as it's good information and represents good practice,
    Using Xlib to write anything other than a toolkit isn't good practice. It's just too low level to be used directly for writing applications.

    Quote Originally Posted by Alfonse Reinheart View Post
    I encourage the use of cross-platform libraries where possible. I've even written several recommendations on the Wiki, discouraging people from manually loading OpenGL functions and linking them directly to several loading libraries. But that doesn't mean I want the knowledge of how to properly handle OpenGL functions to be hidden away. To be something that only those select few "who actually need to know" by some arbitrary metric can actually discover.
    I agree that the parts which relate to OpenGL (i.e. glX* functions and any Xlib functions which directly related to them) are relevant. But that doesn't include X event handling.

    Quote Originally Posted by Alfonse Reinheart View Post
    There is absolutely nothing to be gained by hiding this knowledge from the world. Yes, encourage people not to do it, and tell them why they should use cross-platform solutions. But that doesn't mean you actively prevent them from learning the manual approach.
    You can't meaningfully teach someone X11 programming in a page or two. You can either deal with the OpenGL-specific parts and let them get the rest elsewhere (unfortunately, X is old enough that most of the decent guides are only available in hardcopy form), or provide half-baked (at best) examples which will misinform them.

  4. #14
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948
    It's just too low level to be used directly for writing applications.
    Some people say the same thing about Win32. That doesn't make them right.

    You can't meaningfully teach someone X11 programming in a page or two.
    And it's not trying to; it's just explaining part of X11 programming.

    You can either deal with the OpenGL-specific parts and let them get the rest elsewhere (unfortunately, X is old enough that most of the decent guides are only available in hardcopy form), or provide half-baked (at best) examples which will misinform them.
    Assuming that this is true (and I have no knowledge of X11, so I have no idea one way or the other), then this falls under not being "good information," since it misinforms people about how to make the system work. If you're claiming that the tutorial is doing event handling wrong, then fix it so that it's doing it right.

    Failing that, you could at least explain how it's wrong, rather than simply declaring it to be so.

  5. #15
    Member Regular Contributor
    Join Date
    Jun 2013
    Posts
    498
    Quote Originally Posted by RigidBody View Post
    and the reason is...?
    Reasons, plural. Enough of them that a complete list would be longer than the program. Obvious flaws include: synchronous XGetWindowAttributes() instead of handling ConfigureNotify events, continuing to render if the window is unmapped (minimised), handling one event per redraw rather than all pending events, no error handling.

    But the more general issue is "that's not how you do event processing". As soon as you try to extend it to handle more than one type of event, you'll need to restructure it. If you want to be able to pause the animation (in the sense of not continually redrawing) or skip redraw when the window is minimised, you'll need to restructure it. Etc.

    Quote Originally Posted by RigidBody View Post
    because you, personally, don't like xlib or don't use xlib?
    I don't use it directly unless I absolutely have to. Look at the source (and/or revision logs) for an existing toolkit. Getting an X event framework working properly involves a lot of effort (and testing), and I'd rather not go through that unnecessarily.

    Quote Originally Posted by RigidBody View Post
    that doesnt make any sense at all. i show you how you can initialise an opengl window, but i dont show you how to use it in a program?
    How to do event handling isn't specific to OpenGL. That code would be the same if you were using the core X protocol or XRender. And if you're doing it properly, it doesn't look anything like that example (the source code is available for Xt, GTK, Qt, and wxWidgets; along with several less popular toolkits, most of which never became mainstream because their authors couldn't stomach the years of incremental refinement required to make an X11 toolkit handle all of the messy edge cases).

    Quote Originally Posted by RigidBody View Post
    i have been thinking about making a qt tutorial for a while, but that would not fit on a single page like the xlib example, and it would need much more work to do it in a comprehensible way.
    You'd be lucky to fit a decent Xlib example on 20 pages, assuming that you're offering some explanation as to the whys and wherefores, rather than just dumping code.

    Quote Originally Posted by RigidBody View Post
    qt needs a good amount of c++ knowledge, xlib does not.
    If C++ is the problem, use GTK.

    Quote Originally Posted by RigidBody View Post
    how so?
    Error handling, performance/efficiency, overall integration with the window manager and desktop environment. The only reason the example doesn't have concrete, readily-observable flaws is that it does so little. As soon as you try to add anything to it, the lack of a more generalised event mechanism will bite you.

    Quote Originally Posted by RigidBody View Post
    i have not much info about xcb etc. but i would be much surprised if there is no backward compatibility.
    XCB is even lower-level than Xlib; it doesn't try to be anything more than an interface to the wire protocol. Most of the existing toolkits and libraries are being (or have been) refactored to use it instead of (or as an alternative to) Xlib. In libraries which support both, the XCB code tends to see real-world use while the Xlib version gets unit tests if you're lucky, resulting in the Xlib version suffering from bit-rot.

    The bigger question is whether X11 itself gets displaced by Wayland, or whether Wayland just ends up being the driver API used by the X server (I don't believe they can coexist horizontally). If it's the former, code which uses Xlib directly isn't going to be much use.

  6. #16
    Advanced Member Frequent Contributor
    Join Date
    Aug 2004
    Location
    munich, germany
    Posts
    659
    frankly, i don't care a bit about all that stuff.

    i don't care if checking for configure events is better than using xgetwindowattributes. just because i haven't ever come across any problems using xgetwindowattributes.

    i don't care that rendering continues when minimized- because of the usleep(), the program causes a cpu load of less than 1% anyway.

    it is simple, and it seems to work. it is neither meant to be an xlib tutorial, nor an opengl tutorial. it simply shows how to set up an opengl
    capable window in linux, so the focus is not on the event loop anyway.

    it is a tutorial. a tutorial is the beginning of learning to program something, not the end.
    btw, if you think something should be changed in the code, go ahead and change it. it is a WIKI.
    if you think something should be added, please, go wild, and add it.
    but i predict that nobody will read a 20 page tutorial.

    and if you want people to use qt- you are free to add a qt tutorial to the wiki.
    will be much appreciated, i suppose.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •