wxWidgets wxPen size changes unexpectedly - c++

I've used the following code to draw on a Image using a wxMemoryDC.
To do so I used a wxPen and changed the settings of the pen as in the following code. The code compiles and runs perfectly in windows environment. But in Ubuntu it draws the lines but the pen size stays correctly for a very little time and then the pen size becomes very low.(As shown in the image) It is not an error of the m_pensize variable because it always prints the correct value. Why does this works so strange in ubuntu when it works correctly in windows?.
(m_graphics is the memoryDC here)
if (x<m_backgroundImage.GetWidth() && y< m_backgroundImage.GetHeight()){
m_graphics.SelectObject(m_maskImage);
wxPen* pen;
if (m_isDrawing){
pen = wxThePenList->FindOrCreatePen(*wxRED, m_penSize);
printf("Pen size is %d", m_penSize);
}
else{
pen = wxThePenList->FindOrCreatePen(*wxBLACK, m_penSize);
}
if (m_pentype != Circle){
pen->SetCap(wxCAP_PROJECTING);
}
m_graphics.SetPen(*pen);
m_graphics.DrawLine(m_lastX,m_lastY,x,y);
m_graphics.SelectObject(wxNullBitmap);
}
In windows it is shown Correctly
In linux The pen size is changed unexpectadly.
Your help is greatly appreciated.

If the same code behaves differently in wxMSW and wxGTK, then it's probably a bug in wxWidgets itself, however to fix it it needs to be reproduced in some simple to test way, ideally by making the smallest possible change to the wxWidgets drawing sample and opening a ticket attaching this change as a patch to it.
To simplify the code as much as possible, I'd recommend:
Getting rid of wxThePenList and just creating the pen directly. It's unlikely that the bug is here, but who knows.
Check if it's not due to SetCap() call, this is the most likely candidate IMHO.

Related

OpenCV destroyWindow() not working with multiple windows

I am using openCV library to open and display multiple images. I am doing this with multiple windows created in order to display each image. In order to achieve display of multiple windows at the same time, I am using waitKey() only after the last image.
cv::namedWindow("Window1");
cv::imshow("Window1", myImage1);
cv::namedWindow("Window2");
cv::imshow("Window2", myImage2);
cv::waitKey(1000);
As can be seen from the code, my goal is to give the user 1s of time to press any key, otherwise I want to destroy one of the windows (for the purpose of this question it can be either one). I want to achieve this by using openCV's function destroyWindow().
Below my entire code can be seen:
cv::namedWindow("Window1");
cv::imshow("Window1", myImage1);
cv::namedWindow("Window2");
cv::imshow("Window2", myImage2);
cv::waitKey(1000);
cv::destroyWindow("Window2");
The goal of this code snippet should be that only "Window1" remains displayed, if 1s goes by, with the user not pressing any key.
However, this does not happen. The end result is that none of the windows are destroyed.
I have tested the following code snippet, which results in both windows being closed:
cv::namedWindow("Window1");
cv::imshow("Window1", myImage1);
cv::namedWindow("Window2");
cv::imshow("Window2", myImage2);
cv::waitKey(1000);
cv::destroyWindow("Window1");
cv::destroyWindow("Window2");
The same results when I use destroyAllWindows() function (which makes sense).
My question now is, why can't I destroy only one of the windows?
Additional info:
Using Ubuntu 20.04.
OpenCV version is 4.2.
Working in C++
Changing the order of which window I want to destroy changes nothing.
Tried to replicate it, facing this issue in Python as well on Ubuntu. If you are still stuck, you can try a stopgap solution of reshowing only the one you wanted to show provided the user has pressed a key or not by storing the result of waitKey in some variable. If it is -1 then no key has been pressed.
I have provided a sample solution in Python which you shouldn't face any difficulties converting to C++.
import cv2
img1 = cv2.imread('img1.png')
img2 = cv2.imread('img2.png')
cv2.namedWindow('img1')
cv2.imshow('img1', img1)
cv2.namedWindow('img2')
cv2.imshow('img2', img2)
key = cv2.waitKey(5000)
if key == -1:
cv2.destroyAllWindows()
cv2.imshow('img1', img1)
cv2.waitKey(0)
else:
# do whatever destroy both or keep on showing both using cv2.waitKey(0)
cv2.destroyAllWindows()
I have reached a solution by adding startWindowThread() before adding each of the windows.
An important thing to note is also that I have built openCV using GTK option, so my solution is tested only on GTK not on others.
startWindowThread() is used only with GTK as noted here: https://github.com/opencv/opencv/issues/7562 - for others the function is empty.

c++ (on Clion) for loop stops in the middle with no errors (exit code 0) [duplicate]

When using CLion I have found the output sometimes cuts off.
For example when running the code:
main.cpp
#include <stdio.h>
int main() {
int i;
for (i = 0; i < 1000; i++) {
printf("%d\n", i);
}
fflush(stdout); // Shouldn't be needed as each line ends with "\n"
return 0;
}
Expected Output
The expected output is obviously the numbers 0-999 on each on a new line
Actual Output
After executing the code multiple times within CLion, the output often changes:
Sometimes it executes perfectly and shows all the numbers 0-999
Sometimes it cuts off at different points (e.g. 0-840)
Sometimes it doesn't output anything
The return code is always 0!
Screenshot
Running the code in a terminal (i.e. not in CLion itself)
However, the code outputs the numbers 0-999 perfectly when compiling and running the code using the terminal.
I have spent so much time on this thinking it was a problem with my code and a memory issue until I finally realised that this was just an issue with CLion.
OS: Ubuntu 14.04 LTS
Version: 2016.1
Build: #CL-145.258
Update
A suitable workaround is to run the code in debug mode (thanks to #olaf).
The consensus is that this is an IDE issue. Therefore, I have reported the bug.
A suitable workaround is to execute the code in debug mode (no breakpoint required).
I will update this question, as soon as this bug is fixed.
Update 1
WARNING: You should not change information in registry unless you have been asked specifically by JetBrains. Registry is not in the main menu for a reason! Use the following solution at your own risk!!!
JetBrains have contacted me and provided a suitable solution:
Go to the Find Action Dialog box (CTRL+SHIFT+A)
Search for "Registry..."
Untick run.processes.with.pty
Should then work fine!
Update 2
The bug has been added here:
https://youtrack.jetbrains.com/issue/CPP-6254
Feel free to upvote it!

sdl ttf_rendertext_blended fails randomly

EDIT: Even that the problem still exists, I haven't been able to reproduce this frequently enough to examine it closer. See more info at the end of the question.
I started to develop a game, and I am currently writing basic library for it. I'm using D programming language with SDL-2 and OpenGL 3 (using Derelict3 bindings), on Linux Mint 13 (Maya). Compiler is DMD64 D Compiler v2.067.1, and I rebuild binary each time with 'rdmd'.
To render (changing) text, I create glyphs on-demand. The piece of code I use for this is:
class Font {
...
Texture render(char c) {
if(!(c in rendered)) rendered[c] = texture(to!string(c));
return rendered[c];
}
Texture texture(string text) {
SDL_Color color={255, 255, 255, 255};
auto bitmap = TTF_RenderText_Blended(
font,
std.string.toStringz(text),
color
);
if(!bitmap) {
throw new TTFError(
"TTF_RenderText_Blended: " ~
to!string(TTF_GetError()) ~ ": '" ~ text ~ "'"
);
}
auto texture = new Texture(bitmap);
SDL_FreeSurface(bitmap);
return texture;
}
The problem is that this fails purely randomly. Sometimes it works without any problems. When it fails to render a glyph, it is interesting that it will fail to render the same glyph over and over again. Here is an example when catching the exception I throw:
...
TTF_RenderText_Blended: Text has zero width: '9'
TTF_RenderText_Blended: Text has zero width: '6'
TTF_RenderText_Blended: Text has zero width: '9'
TTF_RenderText_Blended: Text has zero width: '6'
TTF_RenderText_Blended: Text has zero width: '9'
TTF_RenderText_Blended: Text has zero width: '6'
...
(I'm printing score to screen, other numbers showing fine except those few ones). The numbers TTF_RenderText_Blended fails to render vary from run to run, and as mentioned, time to time it renders all the numbers.
One detail is that static strings I render before entering game loop have not yet failed to render, just single letters I use for changing texts.
I'm pretty much out of any ideas, and haven't found anything related to this problem by searching web. Any ideas to look for solutions are very well appreciated.
CURRENT SITUATION: I updated compiler to DMD 2.067.1 and the problem remains (compilers used so far: 2.066.1, 2.067.1). The whole - lets say project family is in the github at the moment:
https://github.com/mkoskim/games
The text glyph rendering function is located in this file:
https://github.com/mkoskim/games/blob/master/engine/ext/font.d
...and it is used from here:
https://github.com/mkoskim/games/blob/master/engine/ext/gui/label.d
The problem occurs mainly/most frequently in the pacman game (although very seldomly just right now):
https://github.com/mkoskim/games/tree/master/testbench/pacman
If you want to try it out, first, read the (hopefully complete enough) installation instructions:
https://github.com/mkoskim/games/blob/master/INSTALL
The project is made for 64-bit Linux Mint Maya, and it is currently not that user friendly and portable from building perspective. Pacman is the only demo that (hopefully) works without game controller. After successful installation of required libraries and tools, you can build it with command:
games/testbench/pacman$ make default
I ran into the exact same issue, and for me it was fixed by keeping the SDL_RWops structure used to create the font (with TTF_OpenFontRW) alive for the whole lifetime of the TTF_Font created by it. I saw you're creating the font with TTF_OpenFontRW as well so I assume this will fix it for you as well. It looks like SDL_ttf relies on this being kept alive, it reads freed memory otherwise.
I know this question is a little bit outdated but I maybe had a similar problem.
I fixed it with simply call SDL_DestroyTexture() every time befor I used TTF_Render_Text_Blended() :)

SDL_RenderCopy() has strange behavior on Raspberry PI

This is driving me up the wall..
I've got a very simple SDL2 program.
It has a array of 3 SDL_Texture pointers.
These textures are filled as follows:
SDL_Texture *myarray[15];
SDL_Surface *surface;
for(int i=0;i<3;i++)
{
char filename[] = "X.bmp";
filename[0] = i + '0';
surface = SDL_LoadBMP(filename);
myarray[i] = SDL_CreateTextureFromSurface(myrenderer,surface);
SDL_FreeSurface(surface);
}
This works, no errors.
In the main loop (which is just a standard event loop waiting for SDL_QUIT, keystrokes and a user-event which a SDL_Timer puts in the event queue every second) I just do (for the timer triggered event):
idx = (idx+1) % 3; // idx is global var initially 0.
SDL_RenderClear(myrenderer);
SDL_RenderCopy(myrenderer, myarray[idx], NULL, NULL);
SDL_RendererPresent(myrenderer);
This works fine for 0.bmp and 1.bmp, but the 3rd image (2.bmp) simply shows as a black field.
This is structural.
If I alternate the first 2 images they are both fine.
If I alternate the 2nd and 3rd image the 3rd image doesn't show.
If I use more than 3 images then 3 and upwards show as black.
Loading order doesn't matter. It starts going wrong with the 3rd image loaded from disk.
All images are properly formatted BMP's.
I even saved 2.bmp back to disk under a different name by using SDL_SaveBMP() after it was loaded to make sure it got loaded in memory OK. The new file is bit for bit identical to the original.
This program, without modifications and the same bmp files, works fine on OSX (XCode5) and Windows (VC++ 2012 Express).
The problem only shows on the Raspberry PI.
I have placed explicit error checks on every call that can leave a result/error-code (not shown in the samples above for brevity) but all of them show "no error".
I have used the latest stable source set of www.libsdl.org and compiled as instructed (configure, make, make install, etc.).
Anybody got any idea what could be going on ?
P.S.
Keyboard input doesn't seem to work either on my PI, but I haven't delved into that yet.
Answering myself as I finally figured it out myself...
I finally went back to the README-raspberrypi.txt that came with the SDL2 sources.
I didn't read it carefully enough the first time around...
Problem 1: I'am running on a FULL-HD display. The PI's default GPU memory is 64MB which is not enough for large displays and double-buffering. As suggested in the README I increased this to 128MB and this solved the black image problem.
Problem 2: Text input wasn't working because my user-account was not in the input group. I had added the default "pi" account to the input group initially, but when I later started using another account I forgot to add that user to the group.
In short: Caught by my own (too) quick skimming of the documentation.

Characters overlapping when they have changed color and are printed backwards

As you can see the upper dark X's are cut even though there is space for them.
This happens because they have changed color and are printed backwards (from right to left).
Is this a bug, faulty code, a bad setup on my system or (I doubt it) like it is supposed to be?
Here is the code that generates this output:
#include <Windows.h>
#include <iostream>
void moveTo(int x,int y){
COORD kord={x,y};
SetConsoleCursorPosition(GetStdHandle(STD_OUTPUT_HANDLE),kord);
}
void setColor(WORD attributes){
SetConsoleTextAttribute(GetStdHandle(STD_OUTPUT_HANDLE), attributes);
}
void main(){
for(int i=9;i+1;i--)
{
moveTo(i,0);
std::cout.put('X');
}
for(int i=-10;i;i++)
{
moveTo(i+10,1);
std::cout.put('X');
}
setColor(8);
for(int i=9;i+1;i--)
{
moveTo(i,2);
std::cout.put('X');
}
for(int i=-10;i;i++)
{
moveTo(i+10,3);
std::cout.put('X');
}
setColor(7);
for(int i=9;i+1;i--)
{
moveTo(i,4);
std::cout.put('X');
}
for(int i=-10;i;i++)
{
moveTo(i+10,5);
std::cout.put('X');
}
std::cin.get();
}
This is a bug in Windows.
As mentioned in the errata by Hans Passant:
I repro too, VS2008 on Win7. Cool bug. Changing the console font fixes it.
Let's use this bug isolation. I recognize this font as Petite Terminal, which implies you both most likely configured this project as a Win32 Console Application. The additional repro with GCC confirms this hypothesis, and we will assume, from a practical standpoint, that all of you were getting a 32-bit console application running inside of a Windows terminal.
The question becomes why it's writing exactly one additional column of pixels in the context of the default terminal font, color 8, and backwards writing into a console screen buffer.
Specifically, let's break this problem up into its component pieces:
When a write is issued, a character is written to a location in the terminal array
When the default color (7) is selected, pixels do not overflow into other buffers within the array
When color 8 is selected, an additional column of pixels is written to the next region of the buffer, which is only visible when the text is recited backwards
Because of the presence of overspill in (3), this is a bug.
Quoting Raymond Chen:
The console rendering model assumes each character fits neatly inside
its fixed-sized cell. When a new character is written to a cell, the
old cell is overprinted with the new character, but if the old
character has overhang or underhang, those extra pixels are left
behind since they "spilled over" the required cell and infected
neighbor cells. Similarly, if a neighboring character "spilled over",
those "spillover pixels" would get erased.
The set of fonts that could be used in the console window was trimmed
to the fonts that were tested and known to work acceptably in console
windows. For English systems, this brought us down to Lucida Console
and Terminal.
...
"Well, that's stupid. You should've stopped me from choosing a font
that so clearly results in nonsense."
And that's what we did.
Not that I'm blaming Raymond on this one, but he authoritatively illustrates this as a "can't happen."
The selection and testing of console fonts for Windows should have caught this. The fact that it's even an issue at all is an aberration.