#xlib

Making a new product Carettochelys insculpta Pig-nosed Turtle

let's make a good pointcloud data first

Use xlib program to checkout the pointcloud ,only black and white

We can see a little internal structure of this turtle,that means good

Cover for my bro X-Lib

Image draw issue on Linux using Xlib

I am developing an application, in which I am receiving images from my window host.. the client side is in Linux using C++.. I am sending JPEG format from server side.. the problem I am facing is that when I receive the image on client, I use “XCreateImage” function to create the “XImage” and when I write this image to a file, it appears to be perfect.. but when I pass this image to “XPutImage”…

For drawables that are double buffered, the contents of the back buffer can be made potentially visible (i.e., become the contents of the front buffer) by calling

void glXSwapBuffers(Display *dpy, GLXDrawable draw);

The contents of the back buffer then become undefined. This operation is a no-op if draw was created with a non-double-buffered GLXFBConfig, or if draw is a GLXPixmap.

All GLX rendering contexts share the same notion of which are front buffers and which are back buffers for a given drawable. This notion is also shared with the X double buffer extension (DBE).

When multiple threads are rendering to the same drawable, only one of them need call glXSwapBuffers and all of them will see the effect of the swap. The client must synchronize the threads that perform the swap and the rendering, using some means outside the scope of GLX, to insure that each new frame is completely rendered before it is made visible.

If dpy and draw are the display and drawable for the calling thread’s current context, glXSwapBuffers performs an implicit glFlush. Subsequent OpenGL commands can be issued immediately, but will not be executed until the buffer swapping has completed, typically during vertical retrace of the display monitor.

If draw is not a valid GLX drawable, glXSwapBuffers generates a GLXBadDrawable error. If dpy and draw are the display and drawable associated with the calling thread’s current context, and if draw is a window that is no longer valid, a GLXBadCurrentDrawable error is generated. If the X Window underlying draw is no longer valid, a GLXBadWindow error is generated.

Concerning Drawables

 In X, a rendering surface is called a Drawable. X provides two types of Drawables: Windows which are located onscreen and Pixmaps which are maintained offscreen. The GLX equivalent to a Window is a GLXWindow and the GLX equivalent to a Pixmap is a GLXPixmap. GLX introduces a third type of drawable, called a GLXPbuffer, for which there is no X equivalent. GLXPbuffers are used for offscreen rendering but they have different semantics than GLXPixmaps that make it easier to allocate them in non-visible frame buffer memory.

GLXWindows, GLXPixmaps and GLXPbuffers are created with respect to a GLXFBConfig; the GLXFBConfig describes the depth of the color buffer components and the types, quantities and sizes of the ancillary buffers (i.e., the depth, accumulation, auxiliary, multisample, and stencil buffers). Double buffering and stereo capability is also fixed by the GLXFBConfig.

Ancillary buffers are associated with a GLXDrawable, not with a rendering context. If several rendering contexts are all writing to the same window, they will share those buffers. Rendering operations to one window never affect the unobscured pixels of another window, or the corresponding pixels of ancillary buffers of that window.

X uses a client–server model where an X server program runs on a computer with a graphical display and communicates with various client programs-- each of which may run on different machines. This reverses the common configuration of client–server systems, where the client runs on the user's computer and the server runs on a remote computer. This is mainly because the X Window terminology takes the perspective of the program, rather than of the end-user or of the hardware: the remote programs connect to the X server display running on the local machine, and thus act as clients; the local X display accepts incoming traffic, and thus acts as a server. 

There are 4 types of packets exchanged between X and its clients in total. These are:

Request: the client requests information from the server or requests it to perform an action. Requests may generate replies, events, and errors.

Reply: the server responds to a request. Not all requests generate replies.

Event: the server sends an event to the client, e.g., keyboard or mouse input, or a window being moved, resized or exposed. Events are selected base on each client's interest which can be specified either a) at the moment of creation b) a change to window's attribute or c) the use of XSelectInput().

Error: the server sends an error packet if a request is invalid. Since requests are queued, error packets generated by a request may not be sent immediately.

It is in the X request and X events that we are interested in. The Xlib functions that send requests to the server usually do not send these requests immediately but store them in a buffer, called the output buffer. The term output in this case refers to the output from the client that is directed to the server: the output buffer can contain all kinds of requests to the server, not only those having a visible effect on the screen.

The output buffer is guaranteed to be flushed ( i.e., all requests done so far are sent to the server ) per these conditions:

After a call to the functions XSync or XFlush.

After a call to a function that returns a value from the server (these functions block until the answer is received)

Some other conditions.

Xlib stores the received events in a queue. The client application can inspect and retrieve events from the queue. While the X server sends events asynchronously, applications using the Xlib library are required to explicitly call Xlib functions for accessing the events in the queue. Some of these functions may block; in this case, they also flush the output buffer.

The content of a window is not guaranteed to be preserved if the window of one of its parts are made not visible. In this case, the application is sent an Expose event when the window of one part of it is made visible again. In particular, content is lost if the X server is not maintaining a backing store of the window content. The client can request backing store for a window to be maintained, but there is no obligation for the server to do so. Therefore, clients cannot assume that backing store is maintained. If a visible part of a window has an unspecified content, an event is sent to notify the client that the window content has to be drawn again.

Also, do note that the use of backing_store is not selected by default owing to a certain memory issues as specified here.