problem with wxSmith and Mac-OSX

[usenechal]

Hi all,

I tried the svn-version 3964 for Mac-OSX (10.4.9, intel) and found a problem with the wxSmith-plugin: everytime I open a wxFrame-Resource, it is shown only for a short time (one second or so). Afterwards the layout-window is constantly grey. When changing some properties like "default pos" in the properties window it's the same behavior. Does anyone noticed the same behavior?

best regards
ulf

[afb]

Yes, unfortunately it's a known problem.

[byo]

Unfortunately I don't have any access to Mac now, so I can't even easily figure out what's wrong with it :/.
I must confess that I forgot about Mac issue for some time (I just had some busy times, as usual ). Maybe it's good time to reactivate it.

The main discussion was here but since this topic does not talk only about wxSmith problems, maybe we should continue here.

From what I've seen there, we're not far away from getting it working.

In attachment is patch which tries to draw some extra text on editor showing what's internally going on. If someone could apply it locally on Mac and give the results I would appreciate this. Afb said here that there's no text shown. But that's really strange because text is drawn just after drawing drag boxes. Maybe there's something wrong with drawing the text :?.

I've also attached some pictures how this patch affect the XP version (don't know how to put attachments right into post, anybody can say how to do it ?).

The one with "Fast Refresh" shows right after showing editor content, the "Timer Refresh" shows periodically each 5 seconds, the "OnPaint Refresh" shows when generic repaing is needed (just like when minimizing and then maximizing C::B back).

Regards
  BYO

[attachment deleted by admin]

[Auria]

I have tried the patch and don't see any text

the whole thing is gray, i have got some components to appear though they tend to appear and disappear randomly

tomorrow i'll probably have time to play with the source code so i can probably give more feedback.

[attachment deleted by admin]

[byo]

That's really weird  :?  I'll have to think about some other patch because the only reason for no extra text I find now is that there's some problem with DC.DrawText or text position. Maybe some big coloured rectangles will be better

Regards
BYO

[Auria]

That's really weird  :?  I'll have to think about some other patch because the only reason for no extra text I find now is that there's some problem with DC.DrawText or text position. Maybe some big coloured rectangles will be better

Regards
BYO

I actually would try std::cout there's no way it doesn't work

Unfortunately I won't be able to try it out soon, as i installed a static wxWidgets 2.8.4 for another app and now the C::B build is all messed up ( compilling wx and C::B on my computer takes hours...  :? )

I'll need to check if there is a way to tell C::B which wx version to use when there are many, i never remember

[byo]

I actually would try std::cout there's no way it doesn't work

Unfortunately I won't be able to try it out soon, as i installed a static wxWidgets 2.8.4 for another app and now the C::B build is all messed up ( compilling wx and C::B on my computer takes hours...  :? )

I'll need to check if there is a way to tell C::B which wx version to use when there are many, i never remember

std::cout won't help here because I want to see what can be shown inside editor area. I've seen on some screens that there are drag boxes and this prooves that something can actually be drawn over edited items. Now we only need to find out what function sucseeded to draw and what actually clears the screen right after.

I've created new patch - instead of drawing text, it draws reactangle filled with red/greed/blue. Can anybody test this patch and send me the result ? I've attached the result of this patch on windows.

BYO



[attachment deleted by admin]

[Auria]

Perhaps i did something wrong?

Code

patching file wxsdrawingwindow.cpp
Hunk #1 FAILED at 82.
Hunk #2 succeeded at 110 (offset -1 lines).
Hunk #3 FAILED at 158.
Hunk #4 succeeded at 250 (offset -1 lines).
patch: **** malformed patch at line 78: Index: wxsdrawingwindow.h

i applied it to the file as it is in svn, rev 4011

[byo]

I probably messed up the patch. Try this one

BYO

[attachment deleted by admin]

[Auria]

I probably messed up the patch. Try this one

BYO

this one applies fine, thanks

i haven't been able to test it yet, i once again messed up my C::B build (errors are expensive when building the app takes over 2 hours )

[Auria]

I probably messed up the patch. Try this one

BYO

this one applies fine, thanks

i haven't been able to test it yet, i once again messed up my C::B build (errors are expensive when building the app takes over 2 hours )

*sigh*

it seems like the --with-wx-config= flag to configure doesn't work, I made clean/dist-clean/etc., then made it point to a wxWidgets 2.8.4 config, and at startup it complains "dyld: Library not loaded: /usr/local/lib/libwx_macu_aui-2.8.0.dylib" so unofrtunately it seems like the end of my efforts, i don't see why it still keeps references to 2.8.0 even after a clean build where i pointed it to 2.8.4

sorry byo unless someone can help with this i can't test the patch :/ I might be repeating myself, but I hate these build systems

[byo]

it seems like the --with-wx-config= flag to configure doesn't work, I made clean/dist-clean/etc., then made it point to a wxWidgets 2.8.4 config, and at startup it complains "dyld: Library not loaded: /usr/local/lib/libwx_macu_aui-2.8.0.dylib" so unofrtunately it seems like the end of my efforts, i don't see why it still keeps references to 2.8.0 even after a clean build where i pointed it to 2.8.4

sorry byo unless someone can help with this i can't test the patch :/ I might be repeating myself, but I hate these build systems

Have you tried to delete all c::b stuff where it's installed in system ? And probably it would be better to delete all sources and check out new copy since makefiles can really leave some rubbish (I hate those build systems too ).

Regards
   BYO

[Auria]

it seems like the --with-wx-config= flag to configure doesn't work, I made clean/dist-clean/etc., then made it point to a wxWidgets 2.8.4 config, and at startup it complains "dyld: Library not loaded: /usr/local/lib/libwx_macu_aui-2.8.0.dylib" so unofrtunately it seems like the end of my efforts, i don't see why it still keeps references to 2.8.0 even after a clean build where i pointed it to 2.8.4

sorry byo unless someone can help with this i can't test the patch :/ I might be repeating myself, but I hate these build systems

Have you tried to delete all c::b stuff where it's installed in system ? And probably it would be better to delete all sources and check out new copy since makefiles can really leave some rubbish (I hate those build systems too ).

Regards
   BYO

haha it's really lame, you need to delete everything and checkout new sources everytime you update wxWidgets...  :?

I will try again later, thanks for the tip (and in for another few hours of building )

[Deschamps]

(..) it's really lame, you need to delete everything and checkout new sources everytime you update wxWidgets (..)

After svn update codeblocks and make clean, have you tried ./configure --prefix=<CB install destination> --with-wx-prefix=<wxW location> for building different releases for C::B when have installed different wxWidgets libraries on your system? Can also use --with-wxdir=<wxW location> when have different uninstalled builds for wxWidgets.

[byo]

I will try again later, thanks for the tip (and in for another few hours of building )

Ok, waiting for reports

I was also working with the problematic code last few hours (it tended to case seg faults on some slower machine running linux) and some parts of the code has been rewritten. So it actually MAY work on MAC after this change. But as usual, only the real machine may show the result And the change require only 2 or 3 files to be recompiled so it will take only minues . I'll only make few more tests and will commit new code into svn.

Anyway waiting for results of current patch, that may be really usefull for me. And I really hope that updated sources will work, at least partially

Regards
  BYO

EDIT: Applied updates to svn, crash-on-linux still exists, but now I got no idea where it comes from, but I still hope that it will fix MAC issues

[Auria]

okay - I haven't gotten your SVN updates yet, I will do that next. (My build problems turned out to be a stupid path problem. oops! I needed a night of sleep to see that ^^)

I have tried with the patched code (rev 4028)
When opening wxSmith, I saw a blue rectangle briefly appear then it turned back grey again. If i hide the app, then bring it to front, i see a red one appear briefly but then disappear too.

If I click on the button icon, first time I saw a blue rect, then a red one, then it all went grey again. When trying to add various components, I see sometimes the blue one, sometimes the red one, sometimes it stays there but now always.

The red one sometimes appears (when the moving the mouse?)

I am now doing the svn update - coming back when it's done

[Auria]

I now have the new code (rev 4051)

Widgets appear when added but disappear shortly afterwards (everything turns grey)

EDIT:I have been doing some tests with std::cout

when trying to add a button

fast repaint
before content changed
after content changed
start fetching sequence
on fetch sequence
refresh timer
fetch sequence phase 2
fetch screen
hide children
erase
erase

hmm paint is called first, then erase. on screen, I see the button appear as repaint is called and disappear as erase is called. If it normal that erase is called now?

void OnEraseBack(wxEraseEvent& event)

well it's empty - I'm just not sure I get how wxSmith displays widgets. Does it use some sort of screen capture?

[byo]

hmm paint is called first, then erase. on screen, I see the button appear as repaint is called and disappear as erase is called. If it normal that erase is called now?

void OnEraseBack(wxEraseEvent& event)

well it's empty - I'm just not sure I get how wxSmith displays widgets. Does it use some sort of screen capture?

Yes, exactly, the screen is captured and the extra content is drawn over it.

And I thing that we have the reason of hiding content - it looks like this empty erase function is responsible for this. Could you comment line 96:

Code

Connect(DrawingPanelId,wxEVT_ERASE_BACKGROUND,(wxObjectEventFunction)&wxsDrawingWindow::DrawingPanel::OnEraseBack);

And check what will happen?
Regards
   BYO

[Auria]

I commented out the line and it still disappears.

I think they disappear on HideChildren() and then the new background is not drawn over it.

[byo]

Hmm, another thing that came into my mind:

Could you put on line 292? :

Code

void wxsDrawingWindow::FetchSequencePhase2()
{
    if ( !Panel ) return;
    if ( IsDestroyed ) return;
    FetchScreen();
    HideChildren();
    Panel->Show();
    DuringFetch = false;
    FastRepaint();            // <----
}

and maybe other solution for this problem:

Code

void wxsDrawingWindow::FetchSequencePhase2()
{
    if ( !Panel ) return;
    if ( IsDestroyed ) return;
    FetchScreen();
    HideChildren();
    DuringFetch = false;        // <--- This and
    Panel->Show();              // <--- this line were swapped
}

Maybe it's just as you say that children are hidden, panel is shown but it doesn't paint.
It may not paint because DuringFetch is still false. On Win and Linux, Panel->Show causes some extra event to be generated and paint procedure is actually done after jumping out of FetchSequencePhase2(). On Mac it may be done while calling Show function.

Regards
   BYO

[Auria]

I tried both with still no luck :?

HOWEVER, i made a little experiment that most likely shows the issue.

i added

Code

if(!Bitmap->SaveFile(wxT("wxSmithScreen.bmp"),wxBITMAP_TYPE_BMP)) std::cout << "saving failed" << std::endl;

at the end of FetchScreen(). I then opened wxSmith, then opened the generated file - and it was empty (transparent). So it seems like fetchScreen() doesn't work.

[byo]

I tried both with still no luck :?

HOWEVER, i made a little experiment that most likely shows the issue.

i added

Code

if(!Bitmap->SaveFile(wxT("wxSmithScreen.bmp"),wxBITMAP_TYPE_BMP)) std::cout << "saving failed" << std::endl;

at the end of FetchScreen(). I then opened wxSmith, then opened the generated file - and it was empty (transparent). So it seems like fetchScreen() doesn't work.

Hmm, doesn't look very optimistic . But there is a way to fetch screen since splashscreen uses this. Maybe the screen is fetched in wrong time or maybe it's fetched properly but cleared right after :/

Could you check this code instead of the one you presented ? It will save each fetch at different bitmap and show number of fetches made. If at least one bitmap will have valid content, it would be huge milestone. There will also be a hint how many fetches are done after each change (it will put number of fetches done so far into stdout). The correct behavior would be to fetch only once after each resource change / editor content resize.

Code

static int Cnt = 0;
if(!Bitmap->SaveFile(wxString::Format(wxT("wxSmithScreen%d.bmp"),++Cnt),wxBITMAP_TYPE_BMP)) std::cout << "saving failed" << std::endl;
std::cout << "fetch " << Cnt << std::endl;

Regards
   BYO

[Auria]

But there is a way to fetch screen since splashscreen uses this.

Actually no The splash screen on mac doesn't use any transparency... not sure why, afb could probably tell you.

Could you check this code instead of the one you presented ?

The screen is not fetched too often, and images are always empty.

Seems like a good conadidate for wxBug report

[afb]

But there is a way to fetch screen since splashscreen uses this.

Actually no The splash screen on mac doesn't use any transparency... not sure why, afb could probably tell you.

Actually it does use transparency, but the old-skool Carbon apis that the wxMac port is using only supported window "regions" (i.e. black-white mask) and not full alpha-channel transparency for the windows...

The fetch screen sorta worked, but since it left a rect around the fetched area and other such artificats it didn't really fool anyone it was transparent. Looked more like "screen dump as background" or such.

[byo]

The fetch screen sorta worked, but since it left a rect around the fetched area and other such artificats it didn't really fool anyone it was transparent. Looked more like "screen dump as background" or such.

Hmm and that "screen dump as background" is exactly what I need . Just need to find out why it fetches empty images instead of what's shown on the screen :?

Auria: I got another idea. Could you put ::wxSleep(few seconds) just before saving the bitmap into files ? It will delay there and let you see what's shown on the screen when the fetching routine runs. If it's empty content, that would mean that items are not shown properly, if it's content of edited window, it would mean that fetching routine is wrong.


BYO

[Auria]

Thanks for leading me - guess what? I have a fix!!!

Code

void wxsDrawingWindow::FetchScreen()
{
    if ( !Bitmap ){ return; }

    wxYield();  // <-----
	
    // Fetching preview directly from screen
	wxScreenDC DC;

As simple as that :lol: now i don't say it fixes everything, but it fixes the most obvious bug. apparently wx just didnt have time to draw before you got the screen capture. maybe it would be better to call for redrawing the window instead of yield.

BTW What's wrong with autotools?? i need to issue the make command several times in a row as it randomly crashes or fails even though the code is valid. just reissuing it many times in a row fixes the problems...

I get seemingly randomly

/bin/sh: line 1: make: No such file or directory

ranlib $  d   
ranlib: can't open file: $ (No such file or directory)
ranlib: can't open file: d (No such file or directory)

[MortenMacFly]

Code

    wxYield();  // <-----

Remember that IMHO you'd better use

Code

Manager::Yield();

at this point...
With regards, Morten.

[byo]

Thanks for leading me - guess what? I have a fix!!!

Code

void wxsDrawingWindow::FetchScreen()
{
    if ( !Bitmap ){ return; }

    wxYield();  // <-----
	
    // Fetching preview directly from screen
	wxScreenDC DC;

As simple as that :lol: now i don't say it fixes everything, but it fixes the most obvious bug. apparently wx just didnt have time to draw before you got the screen capture. maybe it would be better to call for redrawing the window instead of yield.

Wow, thanks for all your investigations Now we really have something 
That's funny because I've used Yields before switching to timers :? Maybe some unique combination: first call timer, than yield is the only available solution. But just to make sure: there's small inline function at the beginning of wxsdrawingwindow.cpp:

Code

    inline RepaintDelayType GetDelayType()
    {
        // Looks like this gives best results so far on both linux and windows
        return TimerNormal;
    }

If you change it's content to return Yield; it will use yields instead of timers. Can you check if this works ? (It shouldn't because it didn't worked ealier).

Anyway, I'd like to avoid calling Yields because it can lead to some rare crashes, expecially when editor is being closed. And there's only one solution that come into my mind now: just call Refresh right before Update in OnFetchSequence (line 236). I assumed that refresh request is sent automaticaly after show/hide stuff, but obviously it was a bad assumption. I'll see how it works on other oses, maybe it's possible to avoid any timer/yield stuff.


Regards
   BYO

[Auria]

Hi Byo,

your code works as well. When using this code components do not disappear. (they do disappear when trying to play with them e.g. clicking on a text area to add text in it but i think it did it with my other code too)

so it looks like

Code

#ifdef __WXMAC__
return Yield;
#else
return TimerNormal;
#endif

[byo]

Ok, I've updated sources so they use Yields on MAC. I also added Refresh() just before Update() and it works even without timers on Win now (and probably on Linux), but it's not as smooth as when using timers . So my request to Auria: Could you test the new code and play with it a little bit? (maybe this Refresh() / Update() sequence will work even withou any yields - using "None" delay type). Anyway, you've writteh that currently there's something shown inside wxSmith but it disappears on some circumstances. Could you describe more exact what are those circumstances? Thanks for your work

Regards
   BYO

[Auria]

Ok, I've updated sources so they use Yields on MAC. I also added Refresh() just before Update() and it works even without timers on Win now (and probably on Linux), but it's not as smooth as when using timers . So my request to Auria: Could you test the new code and play with it a little bit? (maybe this Refresh() / Update() sequence will work even withou any yields - using "None" delay type). Anyway, you've writteh that currently there's something shown inside wxSmith but it disappears on some circumstances. Could you describe more exact what are those circumstances? Thanks for your work

Regards
   BYO

for some reason the latest SVN (4105) doesn't work on mac - widgets are disappearing

(sorry don't have time to test more right now... any idea what is different now?)

[rickg22]

Anyway, I'd like to avoid calling Yields because it can lead to some rare crashes, expecially when editor is being closed.

*shudder*
Yield... crash on exit...
Nightmares... backflashes... the horror, the horror!    :lol:

I had talked to Yiannis a lot about this famous wxYield back in 2005... it was so difficult to find a solution of processing the pending messages and NOT getting into a reentrancy problem.

Ah, it's fun to remember the old times, isn't it... ;-)

[byo]

*shudder*
Yield... crash on exit...
Nightmares... backflashes... the horror, the horror!    :lol:

Exactly, Yield comes with troubles, sooner or later I just learned that from your lessons

for some reason the latest SVN (4105) doesn't work on mac - widgets are disappearing

(sorry don't have time to test more right now... any idea what is different now?)

:? I'd swear this should work... maybe it really require two delay steps as it was done when first results showed up (first comes yield, second is timer, maybe two timers will be enough).

Regards
   BYO

[Auria]

Update :

byo and I have been working together off these forums on the issue.

What was discovered so far:
- wxSmith uses wxScreenDC.
- In a recent udpate, Apple changed Quartz in a way that broke the mac wxScreenDC implementation
- However wxSmith does not need the functionnality of wxScreenDC and it should be possible to use wxClientDC instead.
- Quick code was made to switch to wxClientDC
- It does not yet work however this time it seems like it will be fixable
- BYO is now on vacation i think so no immediate change is to be expected however

[rickg22]

Auria: Please work as much as you can on fixing the problems with wxClientDC. If you manage to get it working, please post a patch. Maybe some of us will have the time and will to post your changes.