>
> Can you try to set/unset documentMode in DragTabBar::DragTabBar and see what
> it does?
>
> JMarc
I’ve inserted setDocumentMode(true/false); and it doesn’t make any difference.
I’ve then set breakpoints in :
QCocoaNativeInterface::setContentBorderEnabled(QWindow *window, bool enable)
Le 11/12/2017 à 12:49, Patrick De Visschere a écrit :
BTW, does the patch that re-adds the backing store work? I'd like to commit it
it for now so that master works until we figure out what to do.
Yes it works. I checked it right away but forgot to inform you.
Good. Is the performance much
Le 11/12/2017 à 11:20, Jean-Marc Lasgouttes a écrit :
From what I saw in the source, the change in the Qt commit is guarded with
if (m_qImage.hasAlphaChannel()) {
OK, with the current code, QRasterBackingStore::beginPaint returns early
if m_image.hasAlphaChannel().
This happens if the
Le 08/12/2017 à 23:53, Patrick De Visschere a écrit :
On 27 Nov 2017, at 22:27, Jean-Marc Lasgouttes > wrote:
But to be sure I would like to see this somewhere confirmed, since
all macos Qt-prgrams must then face this same problem and I’ve not
On 25/10/2017 16:15, Patrick De Visschere wrote:
I do not like much the idea of just restricting the update area, since it seems
very fragile. But we can return to it if needed. There are ways to get all the
coordinates that we need.
I agree. The dimensions passed via update(x,y,w,h) and
Le 23/10/2017 à 23:34, Patrick De Visschere a écrit :
With the patch in place, SingleParUpdate in bufferView::draw is never reached.
So finally you mean that an UpdateRequest is really fired for each
update event (which makes sense :), right?
It would be interesting to set a break on
> On 25 Oct 2017, at 12:21, Jean-Marc Lasgouttes wrote:
>
> Le 23/10/2017 à 23:34, Patrick De Visschere a écrit :
>> With the patch in place, SingleParUpdate in bufferView::draw is never
>> reached.
>
> So finally you mean that an UpdateRequest is really fired for each
> On 25 Oct 2017, at 16:28, Jean-Marc Lasgouttes wrote:
>
> Le 25/10/2017 à 16:15, Patrick De Visschere a écrit :
>>> So finally you mean that an UpdateRequest is really fired for each update
>>> event (which makes sense :), right?
>> The patch turns every update into a
Le 25/10/2017 à 16:15, Patrick De Visschere a écrit :
So finally you mean that an UpdateRequest is really fired for each update event
(which makes sense :), right?
The patch turns every update into a FullScreenUpdate and SingleParUpdate is
then obsolete.
Every call to viewport()->update()
> On 22 Oct 2017, at 23:11, Jean-Marc Lasgouttes wrote:
>
> Le 21 octobre 2017 14:56:36 GMT+02:00, Patrick De Visschere
> a écrit :
>> Jean-Marc,
>>
>> This works because every update is turned into a FullScreenUpdate.
>> Right?
>
> If I understand
Le 21 octobre 2017 14:56:36 GMT+02:00, Patrick De Visschere
a écrit :
>Jean-Marc,
>
>This works because every update is turned into a FullScreenUpdate.
>Right?
If I understand correctly, it turns every update related to an UpdateRequest
event (something internal to qt)
Jean-Marc,
This works because every update is turned into a FullScreenUpdate. Right?
Isn’t this a waste of work?
Do you consider this as a permanent solution?
I’ve tried to solve the problem by using: viewport()->update(0,y,w,h) and thus
specifying the proper coordinates.
If I pass the
Le 19 octobre 2017 22:34:07 GMT+02:00, Patrick De Visschere
a écrit :
>This works as far as I can see.
This is very very good news. I'll commit that as soon as the rest is in a good
enough shape, since the two are related. Thanks a lot for the detective work.
JMarc
This works as far as I can see.
> On 19 Oct 2017, at 17:34, Jean-Marc Lasgouttes wrote:
>
> Le 16/10/2017 à 14:48, Patrick De Visschere a écrit :
>> I’ve defined a watchpoint on what I believe is the backingstore image and
>> this is the complete call stack:
>
> This
Le 16/10/2017 à 14:48, Patrick De Visschere a écrit :
I’ve defined a watchpoint on what I believe is the backingstore image
and this is the complete call stack:
This callstack is very interesting. It tells us that syncBackingStore is
invoked from QWidget::event for the event UpdateRequest
> On 16 Oct 2017, at 11:41, Jean-Marc Lasgouttes wrote:
>
> Le 13/10/2017 à 11:00, Patrick De Visschere a écrit :
>> But I see your point;
>> When I remove the line setting WA_OpaquePaintEvent the problem remains but
>> (most of) the view turns white instead of black;
>>
Le 13/10/2017 à 11:00, Patrick De Visschere a écrit :
But I see your point;
When I remove the line setting WA_OpaquePaintEvent the problem remains but
(most of) the view turns white instead of black;
When I set WA_NoSystemBackground instead the problem remains the same.
When I insert
Le 15/10/2017 à 10:30, Patrick De Visschere a écrit :
I’ve done some more debugging and I believe I’ve found the Qt code that turns
the background black or white.
Om macos (and probably also on windows) Qt uses a QBackingStore for painting. I
couldn’t find a QPlatformBackingStore for linux so
I’ve done some more debugging and I believe I’ve found the Qt code that turns
the background black or white.
Om macos (and probably also on windows) Qt uses a QBackingStore for painting. I
couldn’t find a QPlatformBackingStore for linux so I assume the implementation
is different on linux,
> On 12 Oct 2017, at 21:30, Jean-Marc Lasgouttes wrote:
>
> Le 08/10/2017 à 18:57, pdv a écrit :
>> The new code contains twice a viewport()->update() without specification of
>> a rectangle. Since > Qt normally erases the widget's area before the
>> paintEvent() call
>> I
Le 08/10/2017 à 18:57, pdv a écrit :
The new code contains twice a viewport()->update() without specification
of a rectangle. Since > Qt normally erases the widget's area before the
paintEvent() call
I guess that the whole viewport is erased. Subsequently only part of it
is redrawn except for
On 17/09/2017 19:48, Stephan Witt wrote:
Hi JMarc,
another problem I’ve seen: after running view-pdflatex e.g.
the work area doesn’t show correct background color.
Stephan
The new code contains twice a viewport()->update() without specification
of a rectangle. Since > Qt normally erases the
Am 06.10.2017 um 10:20 schrieb Jean-Marc Lasgouttes :
>
> Le 05/10/2017 à 22:17, Jean-Marc Lasgouttes a écrit :
>> 74 is PolishRequest, which is a weird thing related to Palettes. We might
>> try to set need_resize_ when this event triggers, on the hypotheses that it
>> is
Le 05/10/2017 à 22:17, Jean-Marc Lasgouttes a écrit :
74 is PolishRequest, which is a weird thing related to Palettes. We
might try to set need_resize_ when this event triggers, on the
hypotheses that it is related to some QMacStyle code that resets the
viewport when it should not. We asked to
Le 05/10/2017 à 21:28, Stephan Witt a écrit :
Open file splash.lyx
W>hat is interesing are the places where we switch from normal to black.
frontends/qt4/GuiWorkArea.cpp (702): Screen *not* black before event(207)
frontends/qt4/GuiWorkArea.cpp (746): Screen *not* black after event(207)
> Am 05.10.2017 um 17:09 schrieb Jean-Marc Lasgouttes :
>
> Le 05/10/2017 à 16:46, Stephan Witt a écrit :
>> I attach a screen shot to present the result. Interestingly it’s always
>> black.
>> Perhaps there are two or more images used???
>
> Actually there is only a
Le 05/10/2017 à 16:46, Stephan Witt a écrit :
I attach a screen shot to present the result. Interestingly it’s always
black.
Perhaps there are two or more images used???
Actually there is only a message when the color is black. So the first
time when it is black is before the shortcut
Le 05/10/2017 à 12:19, Stephan Witt a écrit :
I understand that this is no good start for further investigations.
Unfortunately I neither have an idea what to search for with google
nor what to search for in Qt bug database or Qt sources.
The latter I can do when I have more time than now.
Am 05.10.2017 um 10:47 schrieb Jean-Marc Lasgouttes :
>
> Le 05/10/2017 à 10:28, Stephan Witt a écrit :
>>> What is this focus change? can't you run outside of xcode?
>> Yes, but I cannot tell you which event of these four turns the window black.
>> They are coming in an
Le 05/10/2017 à 10:28, Stephan Witt a écrit :
What is this focus change? can't you run outside of xcode?
Yes, but I cannot tell you which event of these four turns the window black.
They are coming in an instant.
So you are sure that this happens with one of these four events. Or wrt
Am 05.10.2017 um 10:17 schrieb Jean-Marc Lasgouttes :
>
> Le 04/10/2017 à 23:53, Stephan Witt a écrit :
>>> Can you tell me what is the point where the window turns black?
>> No, not really. I can tell you it’s on cursor up.
>> This fires 4 events:
>> ShortcutOverride = 51,
>>
Le 04/10/2017 à 23:53, Stephan Witt a écrit :
Can you tell me what is the point where the window turns black?
No, not really. I can tell you it’s on cursor up.
This fires 4 events:
ShortcutOverride = 51,
InputMethodQuery = 207,
KeyPress = 6,
KeyRelease = 7
I cannot debug this because of the
> Am 04.10.2017 um 23:35 schrieb Jean-Marc Lasgouttes :
>
> Le 04/10/17 à 22:40, Stephan Witt a écrit :
>> These are the events printed in terminal window:
>>
>> Start LyX
>> Error: New binding for 'Kontroll-T 1' is overriding old binding...
>> Error: New binding for
Le 04/10/17 à 22:40, Stephan Witt a écrit :
These are the events printed in terminal window:
Start LyX
Error: New binding for 'Kontroll-T 1' is overriding old binding...
Error: New binding for 'Kontroll-T 2' is overriding old binding...
Error: New binding for 'Kontroll-T O' is overriding old
Am 04.10.2017 um 15:30 schrieb Jean-Marc Lasgouttes :
>
> Le 03/10/2017 à 21:32, Jean-Marc Lasgouttes a écrit :
>> So there are some situations where LyX tries to make a minimal redraw
>> because ut thinks that the screen is still correct, although Qt actually
>> wiped it
Le 03/10/2017 à 21:32, Jean-Marc Lasgouttes a écrit :
So there are some situations where LyX tries to make a minimal redraw
because ut thinks that the screen is still correct, although Qt actually
wiped it out. We have to find a way to detect these cases.
Could you try the following debug
Le 03/10/17 à 21:00, Stephan Witt a écrit :
Yes, I’ve built it with Qt4 now and no, the bug isn’t present there.
I have to correct myself. It is there with Qt4 too, but it’s more
difficult to trigger it. Simple cursor down was ok. Running pdflatex
triggers it on Qt4 too. The work area is grey
Am 03.10.2017 um 20:54 schrieb Stephan Witt :
>
> Am 01.10.2017 um 21:17 schrieb Jean-Marc Lasgouttes :
>>
>> Le 30/09/17 à 18:33, Stephan Witt a écrit :
>>> No, that’s not the problem. It looks like a problem with the „backing
>>> store“.
>>
>> I just read
Am 01.10.2017 um 21:17 schrieb Jean-Marc Lasgouttes :
>
> Le 30/09/17 à 18:33, Stephan Witt a écrit :
>> No, that’s not the problem. It looks like a problem with the „backing store“.
>
> I just read about the backing store, but I have problems deciding how to deal
> with it.
Le 30/09/17 à 18:33, Stephan Witt a écrit :
No, that’s not the problem. It looks like a problem with the „backing store“.
I just read about the backing store, but I have problems deciding how to
deal with it. The Qt4 doc mentions it, but only Qt5 has means to
interact with it (and a
Am 30.09.2017 um 17:58 schrieb Jean-Marc Lasgouttes :
>
> Le 29/09/2017 à 10:39, Jean-Marc Lasgouttes a écrit :
>> I suspect I am missing something. I do not see how running view pdflatex may
>> interfere? A screencast, maybe?
>
> Is it that the LyX window is not repainted
Le 29/09/2017 à 10:39, Jean-Marc Lasgouttes a écrit :
I suspect I am missing something. I do not see how running view pdflatex
may interfere? A screencast, maybe?
Is it that the LyX window is not repainted correctly when it is covered
by another one?
JMarc
Le 17/09/2017 à 19:48, Stephan Witt a écrit :
Hi JMarc,
another problem I’ve seen: after running view-pdflatex e.g.
the work area doesn’t show correct background color.
I suspect I am missing something. I do not see how running view pdflatex
may interfere? A screencast, maybe?
JMarc
Le 18/09/2017 à 14:46, Stephan Witt a écrit :
The patch makes no difference again, sorry. Removing the mentioned line
changes it to gray background.
And there are no letters drawn on this background?
It might be that there is a paint event that is sent before the metrics
have been computed.
Am 18.09.2017 um 15:36 schrieb Jean-Marc Lasgouttes :
>
> Le 18/09/2017 à 14:46, Stephan Witt a écrit :
>> The patch makes no difference again, sorry. Removing the mentioned line
>> changes it to gray background.
>
> I am not completely surprised. What does the "painting"
Le 18/09/2017 à 14:46, Stephan Witt a écrit :
The patch makes no difference again, sorry. Removing the mentioned line
changes it to gray background.
I am not completely surprised. What does the "painting" debug flag tell us?
JMarc
Am 18.09.2017 um 14:28 schrieb Jean-Marc Lasgouttes :
>
> Le 18/09/2017 à 12:48, Stephan Witt a écrit :
>> Doesn’t help, sorry.
>> Perhaps the black screen is „painted“ by the null painter?
>
> The NullPainter is really something that cannot paint. It does not rely on Qt
>
Le 18/09/2017 à 12:48, Stephan Witt a écrit :
Doesn’t help, sorry.
Perhaps the black screen is „painted“ by the null painter?
The NullPainter is really something that cannot paint. It does not rely
on Qt at all.
Can you try the following? I had removed these calls but I am not sure
what
Am 18.09.2017 um 12:24 schrieb Jean-Marc Lasgouttes :
>
> Le 17/09/2017 à 22:30, Stephan Witt a écrit :
>> Am 17.09.2017 um 21:27 schrieb Jean-Marc Lasgouttes :
>>>
>>> Le 17/09/2017 à 19:48, Stephan Witt a écrit :
Hi JMarc,
another problem I’ve
Le 17/09/2017 à 22:30, Stephan Witt a écrit :
Am 17.09.2017 um 21:27 schrieb Jean-Marc Lasgouttes :
Le 17/09/2017 à 19:48, Stephan Witt a écrit :
Hi JMarc,
another problem I’ve seen: after running view-pdflatex e.g.
the work area doesn’t show correct background color.
Le 18/09/2017 à 11:50, Stephan Witt a écrit :
I’m providing a mini screen-cast to demonstrate what happens.
1. Open splash
2. Cursor down twice
3. Resize window
Can you try to turn on the "painting" channel? My impression is the the
first paintings are do not use the FullScreenUpdate
Am 18.09.2017 um 11:26 schrieb Jean-Marc Lasgouttes :
>
> Le 17/09/2017 à 22:32, Jean-Marc Lasgouttes a écrit :
>> Yes, it looks like it. I tried to run a bit with valgrind, but did not
>> detect anything useful. It could be related to Richard's font problems.
>
> Do you
Le 17/09/2017 à 22:32, Jean-Marc Lasgouttes a écrit :
Yes, it looks like it. I tried to run a bit with valgrind, but did not
detect anything useful. It could be related to Richard's font problems.
Do you still see this issue after the last pair of fixes?
JMarc
Le 17/09/2017 à 22:30, Stephan Witt a écrit :
Am 17.09.2017 um 21:27 schrieb Jean-Marc Lasgouttes :
Le 17/09/2017 à 19:48, Stephan Witt a écrit :
Hi JMarc,
another problem I’ve seen: after running view-pdflatex e.g.
the work area doesn’t show correct background color.
Am 17.09.2017 um 21:27 schrieb Jean-Marc Lasgouttes :
>
> Le 17/09/2017 à 19:48, Stephan Witt a écrit :
>> Hi JMarc,
>> another problem I’ve seen: after running view-pdflatex e.g.
>> the work area doesn’t show correct background color.
>
> Wow. The situation is worse than I
Le 17/09/2017 à 19:48, Stephan Witt a écrit :
Hi JMarc,
another problem I’ve seen: after running view-pdflatex e.g.
the work area doesn’t show correct background color.
Wow. The situation is worse than I thought. Where does all this black
come from?
JMarc
56 matches
Mail list logo