Re: LyX-Workarea: Background not shown correctly

[Patrick De Visschere]

> 
> 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)
and QMainWindow::setUnifiedTitleAndToolBarOnMac(bool set)

but these are never triggered ...

… because the format() you’ve been following is not from QCocoaBackingStore, 
but from QRasterBackingStore, as shown in this stack ...



… and that’s because the code for the QCocoaBackingStore::format() has changed 
between Qt-5.9 and Qt-5.10;
This is the code for Qt-5.10:

QImage::Format QCocoaBackingStore::format() const
{
if (windowHasUnifiedToolbar())
return QImage::Format_ARGB32_Premultiplied;

return QRasterBackingStore::format();
}

===
The top routine in the stack QSurfaceFormat::hasAlpha() returns:

return d->alphaBufferSize > 0; (with alphaBufferSize=8)

The latter is set in :

QSurfaceFormat QCocoaWindow::format() const
{
QSurfaceFormat format = window()->requestedFormat();

// Upgrade the default surface format to include an alpha channel. The 
default RGB format
// causes Cocoa to spend an unreasonable amount of time converting it to 
RGBA internally.
if (format == QSurfaceFormat())
format.setAlphaBufferSize(8);
return format;
}

===

Re: LyX-Workarea: Background not shown correctly

[Jean-Marc Lasgouttes]

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 worse than with your patch?

JMarc

Re: LyX-Workarea: Background not shown correctly

[Jean-Marc Lasgouttes]

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 cocoa backing store supports an alpha channel.

This is turns depends on  cocoaWindow->m_drawContentBorderGradient:
QImage::Format QCocoaBackingStore::format() const
{
QCocoaWindow *cocoaWindow = static_cast*>(window()->handle());

if (cocoaWindow && cocoaWindow->m_drawContentBorderGradient)
return QImage::Format_ARGB32_Premultiplied;

return QRasterBackingStore::format();
}

This is set by
void QCocoaWindow::setContentBorderEnabled(bool enable)
{
m_drawContentBorderGradient = enable;
applyContentBorderThickness(m_nsWindow);
}


In turn, this is triggered by the native interface
void QCocoaNativeInterface::setContentBorderAreaEnabled(QWindow *window, 
quintptr identifier, bool enable)

{
if (!window)
return;

QCocoaWindow *cocoaWindow = static_cast*>(window->handle());

if (cocoaWindow)
cocoaWindow->setContentBorderAreaEnabled(identifier, enable);
}

This thing can be used by some Cocoa thing I do not understand named 
NativeResourceForIntegrationFunction.
And this native thing is in turn triggered by 
QTabBarPrivate::updateMacBorderMetrics().


Phew!

So, from what I understand, having the backing store transparent makes 
sense when he window has a texture (metal, whatever). In some cases I do 
not yet understand, QTabBar will set this property when it is in 
document mode, which is related to having some border on top and bottom 
of the tab contents.


Can you try to set/unset documentMode in DragTabBar::DragTabBar and see 
what it does?


JMarc

Re: LyX-Workarea: Background not shown correctly

[Jean-Marc Lasgouttes]

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 
been able to find any reference to it.


It would be great to ask about it either in some place where people 
know well about Qt (either a bug, or inter...@qt-project.org 
, or a stackoverflow thing).


I received only one reply stating that the macos-behavior is the 
“standard” one, meaning that update() should specify the rect to be 
updated. That it works on linux without specifying the rect is 
considered luck.


The missing information there was that we set the special opaque flag. 
From what I saw in the source, the change in the Qt commit is guarded with

  if (m_qImage.hasAlphaChannel()) {

This should only trigger when the window is transparent. Is there 
something we should do to tell Qt that our window is _not_ transparent?


I’ve also found further confirmation in a Qt-app (TeXStudio) which uses 
update(rect) to partially update the editor-window.


To me, using update(rect) is nice when your painting code is always full 
painting. In our case, we have chosen a different route. I am not saying 
we should not go your way, but I am resisting a bit :


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.


JMarc

Re: LyX-Workarea: Background not shown correctly

[pdv]

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 the actual area painted 
must match exactly. I cannot judge the penalty of the screen redraws. I doesn’t 
seem to hurt very much.
Nevertheless I have now something which works mostly. There are still problems 
when dragging a selection but I believe these can be solved by fine tuning. The 
other problem is that when opening a document the screen stil turns black.



I'm afraid the latter problem cannot (easily) be solved.
When opening a document (I used a simple one with 3 lines with 1 
character each) viewport()->update() is executed 4x.


2x with update_flags_=ForceDraw and update_strategy=FullScreenUpdate
and 2x with update_strategy=SingleParUpdate

Both FullScreenUpdates are initiated by 
TabWorkArea::on_currentTabChanged(), the second one following a 
QEvent::FocusIn.


Although the second call is redundant this is probably not an oversight.

Unfortunately since the screen has already been drawn after the first 
update(), the tm::drawPargraph code does not redraw it the 2nd time, but 
the screen has been erased by qt again after the second update().


pdv

Re: LyX-Workarea: Background not shown correctly

[Jean-Marc Lasgouttes]

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 QWindow::requestUpdate and see 
whether to is something we do that triggers this effect.


I did and it’s never triggered.


OK.


If I pass the coordinates of the paragraph, I notice that
“SingleParUpdate" actually means “SingleRowUpdate". Since only the
current paragraph is painted black now, except for the current row.


What happens is that the painting code (in TextMetrics::drawParagraph) 
only paints the rows of the paragraph that have changed. This is why you 
see that only the row cursor is repainted. If you do a change that 
changes the cursor row and the next one (by inserting a character), you 
should see several rows repainted.


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.


There is a point that I would like to clear though: is the screen turned 
to black at each event (insertion of a character...), or only when 
certain things happen, like the example of doing a PDF preview like 
Stephan described at the beginning of this thread?



I’m still having problems with the basics. I thought there existed a document 
describing the basics of textMetrics, paragraphMetrics … .
I found something on the wiki but not so much.


Did you take a look at development/PAINTING_ANALYSIS? I try to maintain 
it while doing changes, but it is incomplete, and probably wrong in some 
places.


JMarc

Re: LyX-Workarea: Background not shown correctly

[Patrick De Visschere]

> 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 update 
> event (which makes sense :), right?

The patch turns every update into a FullScreenUpdate and SingleParUpdate is 
then obsolete.
Every call to viewport()->update() leads to a QEvent::updateRequest I guess.

> 
>>> It would be interesting to set a break on QWindow::requestUpdate and see 
>>> whether to is something we do that triggers this effect.
>> I did and it’s never triggered.
> 
> OK.

btw this was about the function requestUpdate(), not the QEvent.

> 
 If I pass the coordinates of the paragraph, I notice that
 “SingleParUpdate" actually means “SingleRowUpdate". Since only the
 current paragraph is painted black now, except for the current row.
> 
> What happens is that the painting code (in TextMetrics::drawParagraph) only 
> paints the rows of the paragraph that have changed. This is why you see that 
> only the row cursor is repainted. If you do a change that changes the cursor 
> row and the next one (by inserting a character), you should see several rows 
> repainted.

Yes I found the crcCheck on a row.
But when forcing a FullScreenUpdate this code becomes useless, since with 
pi.full_repaint=true every line is redrawn.

> 
> 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 the actual area painted 
must match exactly. I cannot judge the penalty of the screen redraws. I doesn’t 
seem to hurt very much.
Nevertheless I have now something which works mostly. There are still problems 
when dragging a selection but I believe these can be solved by fine tuning. The 
other problem is that when opening a document the screen stil turns black.

> 
> There is a point that I would like to clear though: is the screen turned to 
> black at each event (insertion of a character...), or only when certain 
> things happen, like the example of doing a PDF preview like Stephan described 
> at the beginning of this thread?

When typing, the whole screen stays black, except for the current line, which 
looks normal. You don’t have to do anything special to get this.
That’s what I expect: when typing a single character in a row, only that row 
will be repainted but the update() triggers a full screen erase.

With a big document it’s sufficient to scroll a little bit to trigger a 
FullScreenUpdate. So maybe when not typing and moving the mouse around it might 
not always be obvious.
And within a table there is no problem, meaning that the cells do not turn 
black. Moving the mouse over a table seems to trigger a FullScreenUpdate.

> 
>> I’m still having problems with the basics. I thought there existed a 
>> document describing the basics of textMetrics, paragraphMetrics … .
>> I found something on the wiki but not so much.
> 
> Did you take a look at development/PAINTING_ANALYSIS? I try to maintain it 
> while doing changes, but it is incomplete, and probably wrong in some places.

Yes I found that and it helped.

> 
> JMarc




smime.p7s
Description: S/MIME cryptographic signature

Re: LyX-Workarea: Background not shown correctly

[Patrick De Visschere]

> 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 FullScreenUpdate and SingleParUpdate is 
>> then obsolete.
>> Every call to viewport()->update() leads to a QEvent::updateRequest I guess.
> 
> Yes, I meant without the patch that does a full repaint on each full paint 
> event.
> 
>> btw this was about the function requestUpdate(), not the QEvent.
> 
> I suspect they are the same, but the Qt source is really too big for me. I 
> tried to understand what happens, but it is hard to grasp.
> 
>> Yes I found the crcCheck on a row.
>> But when forcing a FullScreenUpdate this code becomes useless, since with 
>> pi.full_repaint=true every line is redrawn.
> 
> Of course, if we force, we force.
> 
>>> 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 the actual area 
>> painted must match exactly. I cannot judge the penalty of the screen 
>> redraws. I doesn’t seem to hurt very much.
>> Nevertheless I have now something which works mostly. There are still 
>> problems when dragging a selection but I believe these can be solved by fine 
>> tuning. The other problem is that when opening a document the screen stil 
>> turns black.
> 
> And the other problem is that we do a lot of useless painting (that is 
> ignored by the clipping but probably still costs us).
> 
>>> There is a point that I would like to clear though: is the screen turned to 
>>> black at each event (insertion of a character...), or only when certain 
>>> things happen, like the example of doing a PDF preview like Stephan 
>>> described at the beginning of this thread?
>> When typing, the whole screen stays black, except for the current line, 
>> which looks normal. You don’t have to do anything special to get this.
>> That’s what I expect: when typing a single character in a row, only that row 
>> will be repainted but the update() triggers a full screen erase.
>> With a big document it’s sufficient to scroll a little bit to trigger a 
>> FullScreenUpdate. So maybe when not typing and moving the mouse around it 
>> might not always be obvious.
>> And within a table there is no problem, meaning that the cells do not turn 
>> black. Moving the mouse over a table seems to trigger a FullScreenUpdate.
> 
> OK, assume that you managed to get afull repaint (with some scrolling for 
> example). Now, if you type a character, does it turn the whole work area to 
> black?
> 

Yes (except for some insets, as always) and when in a table the whole table 
remains normal.

> JMarc




smime.p7s
Description: S/MIME cryptographic signature

Re: LyX-Workarea: Background not shown correctly

[Jean-Marc Lasgouttes]

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() leads to a QEvent::updateRequest I guess.


Yes, I meant without the patch that does a full repaint on each full 
paint event.



btw this was about the function requestUpdate(), not the QEvent.


I suspect they are the same, but the Qt source is really too big for me. 
I tried to understand what happens, but it is hard to grasp.



Yes I found the crcCheck on a row.
But when forcing a FullScreenUpdate this code becomes useless, since with 
pi.full_repaint=true every line is redrawn.


Of course, if we force, we force.


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 the actual area painted 
must match exactly. I cannot judge the penalty of the screen redraws. I doesn’t 
seem to hurt very much.
Nevertheless I have now something which works mostly. There are still problems 
when dragging a selection but I believe these can be solved by fine tuning. The 
other problem is that when opening a document the screen stil turns black.


And the other problem is that we do a lot of useless painting (that is 
ignored by the clipping but probably still costs us).



There is a point that I would like to clear though: is the screen turned to 
black at each event (insertion of a character...), or only when certain things 
happen, like the example of doing a PDF preview like Stephan described at the 
beginning of this thread?


When typing, the whole screen stays black, except for the current line, which 
looks normal. You don’t have to do anything special to get this.
That’s what I expect: when typing a single character in a row, only that row 
will be repainted but the update() triggers a full screen erase.

With a big document it’s sufficient to scroll a little bit to trigger a 
FullScreenUpdate. So maybe when not typing and moving the mouse around it might 
not always be obvious.
And within a table there is no problem, meaning that the cells do not turn 
black. Moving the mouse over a table seems to trigger a FullScreenUpdate.


OK, assume that you managed to get afull repaint (with some scrolling 
for example). Now, if you type a character, does it turn the whole work 
area to black?


JMarc

Re: LyX-Workarea: Background not shown correctly

[Patrick De Visschere]

> 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 correctly, it turns every update related to an UpdateRequest 
> event (something internal to qt) into a full screen update (in the LyX 
> sense). But I think that these updates (those which create the black screen) 
> are not the norm.
> You can check that by adding some debug information along with the new code 
> in my patch to see how often it triggers.

With the patch in place, SingleParUpdate in bufferView::draw is never reached.

> 
> It would be interesting to set a break on QWindow::requestUpdate and see 
> whether to is something we do that triggers this effect.

I did and it’s never triggered.

>> Isn’t this a waste of work?
>> 
>> Do you consider this as a permanent solution?
> 
> Yes maybe, along with other improvement on our draw code. But I might not 
> understand exactly what is happening.
> 
>> I’ve tried to solve the problem by using: viewport()->update(0,y,w,h)
>> and thus specifying the proper coordinates.
> 
> Which one?

The following gives me the correct coordinates for a simple paragraph (for 
tables using top_pit looks better).

void BufferView::rectToUpdate(int *y, int *w, int *h)
{
if(d->update_strategy_ == SingleParUpdate) {
Text & buftext = buffer_.text();
pit_type const bottom_pit = d->cursor_.bottom().pit();
TextMetrics & tm = textMetrics();
*h = tm.parMetrics(bottom_pit).height();
*y = tm.parMetrics(bottom_pit).position() - 
tm.parMetrics(bottom_pit).ascent();
} else {
*y = 0;
*h = height_;
}
*w = width_;
}


> 
>> If I pass the coordinates of the paragraph, I notice that
>> “SingleParUpdate" actually means “SingleRowUpdate". Since only the
>> current paragraph is painted black now, except for the current row.
> 
> Interesting. Does this mean that we could somehow disable completely these 
> black screen paintings ?

Actually I need the coordinates of the current Row instead of those of the 
Paragraph, but sofar I couldn’t find this information. I’m afraid that the 
currrent Row of a paragraph is not cached somewhere.
And this does not work yet when making a selection or moving the cursor around.

It will only work if for every update we can pass via viewport()->update(x, y, 
w,h) the exact area to be painted later. If it’s too large it will be partially 
black and if too small updates will be missed.

> 
> The whole situation is not clear to me as you can see.

I’m still having problems with the basics. I thought there existed a document 
describing the basics of textMetrics, paragraphMetrics … .
I found something on the wiki but not so much.

> 
> JMarc
> 




smime.p7s
Description: S/MIME cryptographic signature

Re: LyX-Workarea: Background not shown correctly

[Jean-Marc Lasgouttes]

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) into a full screen update (in the LyX sense). 
But I think that these updates (those which create the black screen) are not 
the norm.
You can check that by adding some debug information along with the new code in 
my patch to see how often it triggers.

It would be interesting to set a break on QWindow::requestUpdate and see 
whether to is something we do that triggers this effect.
>Isn’t this a waste of work?
>
>Do you consider this as a permanent solution?

Yes maybe, along with other improvement on our draw code. But I might not 
understand exactly what is happening.

>I’ve tried to solve the problem by using: viewport()->update(0,y,w,h)
>and thus specifying the proper coordinates.

Which one?

>If I pass the coordinates of the paragraph, I notice that
>“SingleParUpdate" actually means “SingleRowUpdate". Since only the
>current paragraph is painted black now, except for the current row.

Interesting. Does this mean that we could somehow disable completely these 
black screen paintings ?

The whole situation is not clear to me as you can see.

JMarc

Re: LyX-Workarea: Background not shown correctly

[Patrick De Visschere]

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 coordinates of the paragraph, I notice that “SingleParUpdate" 
actually means “SingleRowUpdate". Since only the current paragraph is painted 
black now, except for the current row. There is also still a problem when 
making a selection and when moving the cursor around.
Therefore I should pass the coordinates of the current row instead, to begin 
with. The selection/cursor problems might be more difficult to solve.

What’s your opinion on this?

pdv 


> On 19 Oct 2017, at 23:24, Jean-Marc Lasgouttes  wrote:
> 
> 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




smime.p7s
Description: S/MIME cryptographic signature

Re: LyX-Workarea: Background not shown correctly

[Jean-Marc Lasgouttes]

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

Re: LyX-Workarea: Background not shown correctly

[Patrick De Visschere]

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 callstack is very interesting. It tells us that syncBackingStore is 
> invoked from QWidget::event for the event UpdateRequest (14). In turn at (16) 
> we have an occasion of cathcing this event and ask for a full redraw.
> 
> Could you try the following pair of patches? The first one is the one I am 
> working on in another thread (but which is not ready yet) and the second is 
> the one of interest here (but it depends of the first one).
> 
> JMarc
> <0001-Allow-multiple-calls-to-processUpdateFlags-before-re.patch><0001-Tentative-patch-fix-black-screen-on-Mac.patch>




smime.p7s
Description: S/MIME cryptographic signature

Re: LyX-Workarea: Background not shown correctly

[Jean-Marc Lasgouttes]

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 (14). In turn at 
(16) we have an occasion of cathcing this event and ask for a full redraw.


Could you try the following pair of patches? The first one is the one I 
am working on in another thread (but which is not ready yet) and the 
second is the one of interest here (but it depends of the first one).


JMarc
From a02bfba3f56307fa08deaa2a4456092507f91d83 Mon Sep 17 00:00:00 2001
From: Jean-Marc Lasgouttes 
Date: Wed, 11 Oct 2017 18:00:48 +0200
Subject: [PATCH] Allow multiple calls to processUpdateFlags before redraw

The goal of this commit is to ensure that a processUpdateFlags call
that requires no redraw will not override a previous one that did
require a redraw.

To this end, the semantics of the flag argument is now different: its
value is now OR'ed with a private update_flags_ variable. This
variable is only reset after the buffer view has actually been
redrawn.

A new Update::ForceRedraw flag has been added. It requires a full
redraw but no metrics computation. It is not used in the main code
(yet), but avoids to compute metrics repeatedly in consecutive
processUpdateFlags calls.

The process is now as follows:
- the FitCursor flag is honored and removed from the flags
- the Force flag is nhonored (full metrics computation) and replaced
  with ForceDraw.

The remaining flags are only then added to the BufferView update
flags, and the update strategy is computed for the next paint event.

Finally the dubious call to updateMacros in updateMetrics has been
removed for performance reasons.
---
 development/PAINTING_ANALYSIS |  21 +++---
 src/BufferView.cpp| 148 +-
 src/BufferView.h  |   7 +-
 src/TextMetrics.cpp   |   7 +-
 src/update_flags.h|  14 +++-
 5 files changed, 104 insertions(+), 93 deletions(-)

diff --git a/development/PAINTING_ANALYSIS b/development/PAINTING_ANALYSIS
index f734edb..ec3566e 100644
--- a/development/PAINTING_ANALYSIS
+++ b/development/PAINTING_ANALYSIS
@@ -60,12 +60,6 @@ cursor.
 
 * Clean-up of drawing code
 
-The goal is to make painting with drawing disable fast enough that it
-can be used after every metrics computation. Then we can separate real
-drawing from metrics.
-
-Other changes are only clean-ups.
-
 ** When a paragraph ends with a newline, compute correctly the height of the extra row.
 ** Merging bv::updateMetrics and tm::metrics
 
@@ -76,7 +70,7 @@ insets. We should re-use the bv::updateMetrics logic:
  + transfer all the logic of bv::updateMetrics to tm.
  + Main InsetText should not be special.
 
-The difficuly for a tall table cell for example, is that it may be
+The difficulty for a tall table cell for example, is that it may be
 necessary to break the whole contents to know the width of the cell.
 
 
@@ -113,11 +107,19 @@ DecorationUpdate). It triggers a recomputation of the metrics when either:
existing metrics. Note that the Update::SinglePar flag is *never*
taken into account.
 
+If a computation of metrics has taken place, Force is removed from the
+flags and ForceDraw is added instead.
+
+It is OK to call processUptateFlags several times before an update. In
+this case, the effects are cumulative.processUpdateFlags execute the
+metrics-related actions, but defers the actual drawing to the next
+paint event.
+
 The screen is drawn (with appropriate update strategy), except when
 update flag is Update::None.
 
 
-** Metrics computation
+** Metrics computation (and nodraw drawing phase)
 
 This is triggered by bv::updateMetrics, which calls tm::redoParagraph for
 all visible paragraphs. Some Paragraphs above or below the screen (needed
@@ -127,6 +129,9 @@ tm::redoParagraph will call Inset::metrics for each inset. In the case
 of text insets, this will invoke recursively tm::metrics, which redoes
 all the paragraphs of the inset.
 
+At the end of the function, bv::updatePosCache is called. It triggers
+a repaint of the document with a NullPainter (a painter that does
+nothing). This has the effect of caching all insets positions.
 
 ** Drawing the work area.
 
diff --git a/src/BufferView.cpp b/src/BufferView.cpp
index 53d374f..737f184 100644
--- a/src/BufferView.cpp
+++ b/src/BufferView.cpp
@@ -228,7 +228,8 @@ enum ScreenUpdateStrategy {
 
 struct BufferView::Private
 {
-	Private(BufferView & bv) : update_strategy_(NoScreenUpdate),
+	Private(BufferView & bv) : update_strategy_(FullScreenUpdate),
+		update_flags_(Update::Force),
 		wh_(0), cursor_(bv),
 		anchor_pit_(0), anchor_ypos_(0),
 		inlineCompletionUniqueChars_(0),
@@ -245,6 +246,8 @@ struct BufferView::Private
 	///
 	ScreenUpdateStrategy update_strategy_;
 	///
+	Update::flags update_flags_;

Re: LyX-Workarea: Background not shown correctly

[Patrick De Visschere]

> 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;
>> When I set WA_NoSystemBackground instead the problem remains the same.
>> When I insert viewport()->update(0,0,500,500) then everything outside this 
>> square remains untouched but the problem persists within that square.
> 
> Did you try setting both WA_OpaquePaintEvent and WA_NoSystemBackground?

It doesn’t make a difference.

> 
> Does it make a difference to set them on GuiWorkarea too (additionally to the 
> viewport)?

No. I didn’t try all combinations but adding WA_OpaquePaintEvent and then also 
WA_NoSystemBackground does not make a difference.

pdv

> 
> JMarc




smime.p7s
Description: S/MIME cryptographic signature

Re: LyX-Workarea: Background not shown correctly

[Jean-Marc Lasgouttes]

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 viewport()->update(0,0,500,500) then everything outside this 
square remains untouched but the problem persists within that square.


Did you try setting both WA_OpaquePaintEvent and WA_NoSystemBackground?

Does it make a difference to set them on GuiWorkarea too (additionally 
to the viewport)?


JMarc

Re: LyX-Workarea: Background not shown correctly

[Jean-Marc Lasgouttes]

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 assume the implementation 
is different on linux, which would explain the different behaviour.

When issuing an viewport()->update() the region (the complete viewport if no 
smaller area is specified) is marked as dirty and at paint time is then repainted, 
via QWidgetBackingStore::doSync().
In QRasterBackingStore::beginPaint() the region is initially filled with a 
color Qt::transparent which has alpha=r=g=b=0 which will leave the screen black 
if not overwritten.


Very good finding Patrick! Where is the relevant code?

What I would like to know now is:
1. when is invalidation triggered? There are paint events that manage to 
update the existing screen, so invalidation has to depend on something else

2. can we avoid invalidation by setting some flag?
3. if we cannot avoid it, cn we predict that it happened and do a full 
screen repaint in this case?



When WA_OpaquePaintEvent is not set this is followed by a paintBackground() 
call which fills the region with the autoFillBrush-color which has all ones. 
This will leave the screen white if not overwritten.

Depending on the update_strategy_ only a part of the screen is overwritten by 
lyx, leaving the rest black or white.
I assume that in the tests I’ve described previously all actions restoring the 
normal view somehow trigger a FullScreenUpdate.


I agree with this analysis.

JMarc

Re: LyX-Workarea: Background not shown correctly

[Patrick De Visschere]

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, which would explain the different behaviour.

When issuing an viewport()->update() the region (the complete viewport if no 
smaller area is specified) is marked as dirty and at paint time is then 
repainted, via QWidgetBackingStore::doSync().
In QRasterBackingStore::beginPaint() the region is initially filled with a 
color Qt::transparent which has alpha=r=g=b=0 which will leave the screen black 
if not overwritten.

When WA_OpaquePaintEvent is not set this is followed by a paintBackground() 
call which fills the region with the autoFillBrush-color which has all ones. 
This will leave the screen white if not overwritten.

Depending on the update_strategy_ only a part of the screen is overwritten by 
lyx, leaving the rest black or white.
I assume that in the tests I’ve described previously all actions restoring the 
normal view somehow trigger a FullScreenUpdate.

pdv

> 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 guess that the whole viewport is erased. Subsequently only part of it is 
>> redrawn except for the case FullScreenUpdate and in that case there is no 
>> problem.
> 
> Actually, we use
>   viewport()->setAttribute(Qt::WA_OpaquePaintEvent);
> to ask Qt not to overwrite it. It seems to work on Linux.
> 
> Please feel free to look at the code and docs (QWidget and 
> QAbstractScrollArea) and tell us what I may have missed. I just saw that we 
> should override viewportEvent() instead of event(), but I am not sure that it 
> would make a difference.
> 
> Can you compile master? Do you see the issue?
> 
> JMarc




smime.p7s
Description: S/MIME cryptographic signature

Re: LyX-Workarea: Background not shown correctly

[Patrick De Visschere]

> 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 guess that the whole viewport is erased. Subsequently only part of it is 
>> redrawn except for the case FullScreenUpdate and in that case there is no 
>> problem.
> 
> Actually, we use
>   viewport()->setAttribute(Qt::WA_OpaquePaintEvent);
> to ask Qt not to overwrite it. It seems to work on Linux.

I compared the old and the new code and noticed that in the old code update(x, 
y, w, h) was always used with coordinates.
This explanation seemed to make some sense since often a single line remains 
indeed visible (see tests below).
And when I force a FullScreenUpdate in BufferView::draw then the problem goes 
away.

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 viewport()->update(0,0,500,500) then everything outside this 
square remains untouched but the problem persists within that square.

It seems that update(area) restricts updating to the selected area, but 
apparently (at least on macos) one is then obliged to redraw that area 
completely.

The Qt-docs read as follows:
"Qt::WA_OpaquePaintEventIndicates that the widget paints all its pixels 
when it receives a paint event. Thus, it is not required for operations like 
updating, resizing, scrolling and focus changes to erase the widget before 
generating paint events. …."

I understand this as: since the widget will repaint all its pixels, there is no 
need (for Qt) to erase the widget.

Another fragment, dealing with an example, reads:
"The right widget has the Qt::WA_OpaquePaintEvent widget attribute set. This 
indicates that the widget will paint over its entire area with opaque colors. 
The widget's area will initially be uninitialized, represented in the diagram 
with a red diagonal grid pattern that shines through the overpainted area. The 
Qt::WA_OpaquePaintArea attribute is useful for widgets that need to paint their 
own specialized contents quickly and do not need a default filled background."

Apparently “uninitialized” means “black".

I have no idea why this turns out correctly under linux.

> 
> Please feel free to look at the code and docs (QWidget and 
> QAbstractScrollArea) and tell us what I may have missed. I just saw that we 
> should override viewportEvent() instead of event(), but I am not sure that it 
> would make a difference.
> 
> Can you compile master? Do you see the issue?

Yes and yes;
Here are some observations (I used the Help/Introduction for testing):

- Clicking anywhere in the window (or when scrolling) restores the view.
- Inserting a CR anywhere restores the view.
- Selecting anything by double clicking turns the screen black, except for some 
insets (like LYX, a footnote, Table of Contents) which remain visible.
- Hovering with the mouse over a footnote or Table of Contents restores the 
view.
- When moving the cursor up/down with the up/down keys usually only one line is 
visible (in addition to the elements mentioned higher) but it’s the line 
above/below the one containing the cursor.
- This is also true when starting from a normal view. Moving the cursor up/down 
leaves the line visible where the cursor was positioned. However when a word is 
marked by the spellchecker then one must move the cursor an additional line 
before the view goes black (one can thus move the cursor within 3 lines without 
going black).
- When moving the cursor horizontally with the arrow keys; the screen goes 
black except for the current line (and the insets).
- Moving the cursor horizontally in a word marked by the spellchecker causes no 
problem. The view goes black only when entering an adjacent word.
- Sometimes the view is completely blacked, also the special insets. E.g. when 
bringing the window to the foreground.

Replacing GuiWorkArea::event() by viewportEvent() does not make a difference.

If you have a suggestion for a specific test, let me know.

> 
> JMarc




smime.p7s
Description: S/MIME cryptographic signature

Re: LyX-Workarea: Background not shown correctly

[Jean-Marc Lasgouttes]

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 the case FullScreenUpdate and in that case there 
is no problem.


Actually, we use
viewport()->setAttribute(Qt::WA_OpaquePaintEvent);
to ask Qt not to overwrite it. It seems to work on Linux.

Please feel free to look at the code and docs (QWidget and 
QAbstractScrollArea) and tell us what I may have missed. I just saw that 
we should override viewportEvent() instead of event(), but I am not sure 
that it would make a difference.


Can you compile master? Do you see the issue?

JMarc

Re: LyX-Workarea: Background not shown correctly

[pdv]

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 widget's area before the 
paintEvent() call
I guess that the whole viewport is erased. Subsequently only part of it 
is redrawn except for the case FullScreenUpdate and in that case there 
is no problem.


P. De Visschere

Re: LyX-Workarea: Background not shown correctly

[Stephan Witt]

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 related to some QMacStyle code that resets the viewport when it should 
>> not. We asked to leave the viewport alone by setting WA_OpaquePaint.
> 
>> Indeed, in the handling of QEvent::Tooltip it seems that there needs to be a 
>> full repaint when the tooltip is removed. I am not sure why it is not a 
>> problem on linux.
> 
> Could you try the following, on top of the debug patch if possible. If we are 
> lucky, some cases may improve :)
> 
> JMarc
> 
> <0001-Fix-first-try.patch>

This leads to:

Open splash.lyx, focus in, focus out
frontends/qt4/GuiWorkArea.cpp (702): Screen *not* black before event(68)
frontends/qt4/GuiWorkArea.cpp (754): Screen *not* black after event(68)
frontends/qt4/GuiWorkArea.cpp (702): Screen *not* black before event(152)
frontends/qt4/GuiWorkArea.cpp (754): Screen *not* black after event(152)
frontends/qt4/GuiWorkArea.cpp (702): Screen *not* black before event(109)
frontends/qt4/GuiWorkArea.cpp (754): Screen *not* black after event(109)
frontends/qt4/GuiWorkArea.cpp (702): Screen *not* black before event(21)
frontends/qt4/GuiWorkArea.cpp (754): Screen *not* black after event(21)
frontends/qt4/GuiWorkArea.cpp (702): Screen *not* black before event(75)
frontends/qt4/GuiWorkArea.cpp (754): Screen *not* black after event(75)
frontends/qt4/GuiWorkArea.cpp (702): Screen *not* black before event(69)
frontends/qt4/GuiWorkArea.cpp (754): Screen *not* black after event(69)
frontends/qt4/GuiWorkArea.cpp (702): Screen *not* black before event(69)
frontends/qt4/GuiWorkArea.cpp (754): Screen *not* black after event(69)
frontends/qt4/GuiWorkArea.cpp (702): Screen *not* black before event(69)
frontends/qt4/GuiWorkArea.cpp (754): Screen *not* black after event(69)
frontends/qt4/GuiWorkArea.cpp (702): Screen *not* black before event(13)
frontends/qt4/GuiWorkArea.cpp (754): Screen *not* black after event(13)
frontends/qt4/GuiWorkArea.cpp (702): Screen *not* black before event(14)
frontends/qt4/GuiWorkArea.cpp (754): Screen *not* black after event(14)
frontends/qt4/GuiWorkArea.cpp (702): Screen *not* black before event(17)
frontends/qt4/GuiWorkArea.cpp (754): Screen *not* black after event(17)
frontends/qt4/GuiWorkArea.cpp (702): Screen *not* black before event(26)
frontends/qt4/GuiWorkArea.cpp (754): Screen *not* black after event(26)
frontends/qt4/GuiWorkArea.cpp (702): Screen *not* black before event(8)
frontends/qt4/GuiWorkArea.cpp (754): Screen *not* black after event(8)
frontends/qt4/GuiWorkArea.cpp (702): Screen *not* black before event(207)
frontends/qt4/GuiWorkArea.cpp (754): Screen *not* black after event(207)
frontends/qt4/GuiWorkArea.cpp (702): Screen black before event(74)
frontends/qt4/GuiWorkArea.cpp (750): Screen *not* black after event(74)
frontends/qt4/GuiWorkArea.cpp (702): Screen *not* black before event(78)
frontends/qt4/GuiWorkArea.cpp (754): Screen *not* black after event(78)
frontends/qt4/GuiWorkArea.cpp (702): Screen *not* black before event(43)
frontends/qt4/GuiWorkArea.cpp (754): Screen *not* black after event(43)
frontends/qt4/GuiWorkArea.cpp (702): Screen *not* black before event(76)
frontends/qt4/GuiWorkArea.cpp (754): Screen *not* black after event(76)
frontends/qt4/GuiWorkArea.cpp (702): Screen *not* black before event(76)
frontends/qt4/GuiWorkArea.cpp (754): Screen *not* black after event(76)
frontends/qt4/GuiWorkArea.cpp (702): Screen *not* black before event(23)
frontends/qt4/GuiWorkArea.cpp (754): Screen *not* black after event(23)
frontends/qt4/GuiWorkArea.cpp (702): Screen *not* black before event(23)
frontends/qt4/GuiWorkArea.cpp (754): Screen *not* black after event(23)
frontends/qt4/GuiWorkArea.cpp (702): Screen *not* black before event(25)
frontends/qt4/GuiWorkArea.cpp (754): Screen *not* black after event(25)
frontends/qt4/GuiWorkArea.cpp (702): Screen *not* black before event(9)
frontends/qt4/GuiWorkArea.cpp (754): Screen *not* black after event(9)
focus in, focus out
frontends/qt4/GuiWorkArea.cpp (702): Screen *not* black before event(8)
frontends/qt4/GuiWorkArea.cpp (754): Screen *not* black after event(8)
frontends/qt4/GuiWorkArea.cpp (702): Screen *not* black before event(207)
frontends/qt4/GuiWorkArea.cpp (754): Screen *not* black after event(207)
frontends/qt4/GuiWorkArea.cpp (702): Screen *not* black before event(24)
frontends/qt4/GuiWorkArea.cpp (754): Screen *not* black after event(24)
frontends/qt4/GuiWorkArea.cpp (702): Screen *not* black before event(207)
frontends/qt4/GuiWorkArea.cpp (754): Screen *not* black after event(207)
frontends/qt4/GuiWorkArea.cpp (702): Screen *not* black before event(10)
frontends/qt4/GuiWorkArea.cpp (754): Screen *not* black after event(10)
frontends/qt4/GuiWorkArea.cpp (702): Screen *not* black before event(184)

Re: LyX-Workarea: Background not shown correctly

[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 related to some QMacStyle code that resets the 
viewport when it should not. We asked to leave the viewport alone by 
setting WA_OpaquePaint.


Indeed, in the handling of QEvent::Tooltip it seems that there needs to 
be a full repaint when the tooltip is removed. I am not sure why it is 
not a problem on linux.


Could you try the following, on top of the debug patch if possible. If 
we are lucky, some cases may improve :)


JMarc

From 0bfd8e133ad9063d1a8d19e115388e812584a953 Mon Sep 17 00:00:00 2001
From: Jean-Marc Lasgouttes 
Date: Fri, 6 Oct 2017 10:18:47 +0200
Subject: [PATCH] Fix - first try

---
 src/frontends/qt4/GuiWorkArea.cpp | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/src/frontends/qt4/GuiWorkArea.cpp b/src/frontends/qt4/GuiWorkArea.cpp
index 4ec72d4..5f144a7 100644
--- a/src/frontends/qt4/GuiWorkArea.cpp
+++ b/src/frontends/qt4/GuiWorkArea.cpp
@@ -713,6 +713,8 @@ bool GuiWorkArea::event(QEvent * e)
 			else
 QToolTip::hideText();
 		}
+		d->need_resize_ = true;
+		viewport()->update();
 		// Don't forget to accept the event!
 		e->accept();
 		if (isBlack())
@@ -747,6 +749,11 @@ bool GuiWorkArea::event(QEvent * e)
 		return QAbstractScrollArea::event(e);
 	}
 
+	case QEvent::PolishRequest:
+		d->need_resize_ = true;
+		viewport()->update();
+		return QAbstractScrollArea::event(e);
+
 	default:
 		if (isBlack())
 			LYXERR0("Screen black after event(" << e->type() << ")");
-- 
2.7.4

Re: LyX-Workarea: Background not shown correctly

[Jean-Marc Lasgouttes]

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)
frontends/qt4/GuiWorkArea.cpp (702): Screen black before event(74)
frontends/qt4/GuiWorkArea.cpp (746): Screen black after event(74)


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 leave the viewport alone by 
setting WA_OpaquePaint.



frontends/qt4/GuiWorkArea.cpp (702): Screen *not* black before event(110)
frontends/qt4/GuiWorkArea.cpp (717): Screen *not* black after event(110)
frontends/qt4/GuiWorkArea.cpp (702): Screen black before event(51)
frontends/qt4/GuiWorkArea.cpp (725): Screen black after event(51)


110 is Tooltip. Indeed if a tooltip is shown on screen, we can assume 
that on next repaint it would be a good idea to do a full repaint, so 
need_resize_ may be useful, or at least a full redraw if we do not want 
to recompute the metrics.


Indeed, in the handling of QEvent::Tooltip it seems that there needs to 
be a full repaint when the tooltip is removed. I am not sure why it is 
not a problem on linux.


JMarc

Re: LyX-Workarea: Background not shown correctly

[Stephan Witt]

> 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 message when the color is black. So the first time 
> when it is black is before the shortcut override (51) event. We should maybe 
> add messages when the screen is OK too. I do not know what to look for.
> 
> It looks like grabWidget is not good in Qt5, this updated patch may be better.
> 
> I have tried to look a bit at the qt sources, but this is too complicated for 
> me...
> 
> JMarc
> 
> <0001-debug2.1.patch>

With message for black and not black (patch attached) I get:

Open file splash.lyx
frontends/qt4/GuiWorkArea.cpp (702): Screen *not* black before event(68)
frontends/qt4/GuiWorkArea.cpp (746): Screen *not* black after event(68)
frontends/qt4/GuiWorkArea.cpp (702): Screen *not* black before event(152)
frontends/qt4/GuiWorkArea.cpp (746): Screen *not* black after event(152)
frontends/qt4/GuiWorkArea.cpp (702): Screen *not* black before event(109)
frontends/qt4/GuiWorkArea.cpp (746): Screen *not* black after event(109)
frontends/qt4/GuiWorkArea.cpp (702): Screen *not* black before event(21)
frontends/qt4/GuiWorkArea.cpp (746): Screen *not* black after event(21)
frontends/qt4/GuiWorkArea.cpp (702): Screen *not* black before event(75)
frontends/qt4/GuiWorkArea.cpp (746): Screen *not* black after event(75)
frontends/qt4/GuiWorkArea.cpp (702): Screen *not* black before event(69)
frontends/qt4/GuiWorkArea.cpp (746): Screen *not* black after event(69)
frontends/qt4/GuiWorkArea.cpp (702): Screen *not* black before event(69)
frontends/qt4/GuiWorkArea.cpp (746): Screen *not* black after event(69)
frontends/qt4/GuiWorkArea.cpp (702): Screen *not* black before event(69)
frontends/qt4/GuiWorkArea.cpp (746): Screen *not* black after event(69)
frontends/qt4/GuiWorkArea.cpp (702): Screen *not* black before event(13)
frontends/qt4/GuiWorkArea.cpp (746): Screen *not* black after event(13)
frontends/qt4/GuiWorkArea.cpp (702): Screen *not* black before event(14)
frontends/qt4/GuiWorkArea.cpp (746): Screen *not* black after event(14)
frontends/qt4/GuiWorkArea.cpp (702): Screen *not* black before event(17)
frontends/qt4/GuiWorkArea.cpp (746): Screen *not* black after event(17)
frontends/qt4/GuiWorkArea.cpp (702): Screen *not* black before event(26)
frontends/qt4/GuiWorkArea.cpp (746): Screen *not* black after event(26)
frontends/qt4/GuiWorkArea.cpp (702): Screen *not* black before event(8)
frontends/qt4/GuiWorkArea.cpp (746): Screen *not* black after event(8)
frontends/qt4/GuiWorkArea.cpp (702): Screen *not* black before event(207)
frontends/qt4/GuiWorkArea.cpp (746): Screen *not* black after event(207)
frontends/qt4/GuiWorkArea.cpp (702): Screen black before event(74)
frontends/qt4/GuiWorkArea.cpp (746): Screen black after event(74)
frontends/qt4/GuiWorkArea.cpp (702): Screen black before event(78)
frontends/qt4/GuiWorkArea.cpp (746): Screen black after event(78)
frontends/qt4/GuiWorkArea.cpp (702): Screen black before event(43)
frontends/qt4/GuiWorkArea.cpp (746): Screen black after event(43)
frontends/qt4/GuiWorkArea.cpp (702): Screen black before event(76)
frontends/qt4/GuiWorkArea.cpp (746): Screen black after event(76)
frontends/qt4/GuiWorkArea.cpp (702): Screen *not* black before event(76)
frontends/qt4/GuiWorkArea.cpp (746): Screen *not* black after event(76)
frontends/qt4/GuiWorkArea.cpp (702): Screen *not* black before event(10)
frontends/qt4/GuiWorkArea.cpp (746): Screen *not* black after event(10)
frontends/qt4/GuiWorkArea.cpp (702): Screen *not* black before event(11)
frontends/qt4/GuiWorkArea.cpp (746): Screen *not* black after event(11)
frontends/qt4/GuiWorkArea.cpp (702): Screen *not* black before event(23)
frontends/qt4/GuiWorkArea.cpp (746): Screen *not* black after event(23)
frontends/qt4/GuiWorkArea.cpp (702): Screen *not* black before event(23)
frontends/qt4/GuiWorkArea.cpp (746): Screen *not* black after event(23)
frontends/qt4/GuiWorkArea.cpp (702): Screen *not* black before event(25)
frontends/qt4/GuiWorkArea.cpp (746): Screen *not* black after event(25)
frontends/qt4/GuiWorkArea.cpp (702): Screen *not* black before event(9)
frontends/qt4/GuiWorkArea.cpp (746): Screen *not* black after event(9)
Focus in - cursor down - Focus out
frontends/qt4/GuiWorkArea.cpp (702): Screen *not* black before event(8)
frontends/qt4/GuiWorkArea.cpp (746): Screen *not* black after event(8)
frontends/qt4/GuiWorkArea.cpp (702): Screen *not* black before event(207)
frontends/qt4/GuiWorkArea.cpp (746): Screen *not* black after event(207)
frontends/qt4/GuiWorkArea.cpp (702): Screen *not* black before event(24)
frontends/qt4/GuiWorkArea.cpp (746): Screen *not* black after event(24)
frontends/qt4/GuiWorkArea.cpp (702): Screen *not* black before event(207)
frontends/qt4/GuiWorkArea.cpp (746): Screen *not* black after event(207)

Re: LyX-Workarea: Background not shown correctly

[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 message when the color is black. So the first 
time when it is black is before the shortcut override (51) event. We 
should maybe add messages when the screen is OK too. I do not know what 
to look for.


It looks like grabWidget is not good in Qt5, this updated patch may be 
better.


I have tried to look a bit at the qt sources, but this is too 
complicated for me...


JMarc

From 4464cd20e694bb8425a6b5e61a4125f06d655086 Mon Sep 17 00:00:00 2001
From: Jean-Marc Lasgouttes 
Date: Wed, 4 Oct 2017 15:26:41 +0200
Subject: [PATCH] debug2.1

---
 src/frontends/qt4/GuiWorkArea.cpp | 33 ++---
 src/frontends/qt4/GuiWorkArea.h   |  3 +++
 2 files changed, 33 insertions(+), 3 deletions(-)

diff --git a/src/frontends/qt4/GuiWorkArea.cpp b/src/frontends/qt4/GuiWorkArea.cpp
index a24e8da..4ec72d4 100644
--- a/src/frontends/qt4/GuiWorkArea.cpp
+++ b/src/frontends/qt4/GuiWorkArea.cpp
@@ -268,13 +268,13 @@ GuiWorkArea::Private::~Private()
 
 
 GuiWorkArea::GuiWorkArea(QWidget * /* w */)
-: d(new Private(this))
+	: init_done_(false), d(new Private(this))
 {
 }
 
 
 GuiWorkArea::GuiWorkArea(Buffer & buffer, GuiView & gv)
-: d(new Private(this))
+	: init_done_(false), d(new Private(this))
 {
 	setGuiView(gv);
 	buffer.params().display_pixel_ratio = theGuiApp()->pixelRatio();
@@ -432,7 +432,7 @@ void GuiWorkArea::startBlinkingCaret()
 	d->showCaret();
 
 	//we're not supposed to cache this value.
-	int const time = QApplication::cursorFlashTime() / 2;
+	int const time = 100; //QApplication::cursorFlashTime() / 2;
 	if (time <= 0)
 		return;
 	d->caret_timeout_.setInterval(time);
@@ -684,8 +684,23 @@ void GuiWorkArea::scrollTo(int value)
 }
 
 
+bool GuiWorkArea::isBlack()
+{
+	if (!init_done_)
+		return false;
+#if (QT_VERSION < 0x05)
+	QImage qi = QPixmap::grabWidget(viewport(), QRect(0,0,10,10)).toImage();
+#else
+	QImage qi = viewport()->grab(QRect(0,0,10,10)).toImage();
+#endif
+	return qi.pixel(0,0) == 0xff00;
+}
+
+
 bool GuiWorkArea::event(QEvent * e)
 {
+	if (isBlack())
+		LYXERR0("Screen black before event(" << e->type() << ")");
 	switch (e->type()) {
 	case QEvent::ToolTip: {
 		QHelpEvent * helpEvent = static_cast(e);
@@ -700,6 +715,8 @@ bool GuiWorkArea::event(QEvent * e)
 		}
 		// Don't forget to accept the event!
 		e->accept();
+		if (isBlack())
+			LYXERR0("Screen black after event(" << e->type() << ")");
 		return true;
 	}
 
@@ -707,6 +724,8 @@ bool GuiWorkArea::event(QEvent * e)
 		// keyPressEvent is ShortcutOverride-aware and only accepts the event in
 		// this case
 		keyPressEvent(static_cast(e));
+		if (isBlack())
+			LYXERR0("Screen black after event(" << e->type() << ")");
 		return e->isAccepted();
 
 	case QEvent::KeyPress: {
@@ -719,12 +738,18 @@ bool GuiWorkArea::event(QEvent * e)
 ke->modifiers() == Qt::ShiftModifier
 || ke->modifiers() == Qt::NoModifier))) {
 			keyPressEvent(ke);
+			if (isBlack())
+LYXERR0("Screen black after event(" << e->type() << ")");
 			return true;
 		}
+		if (isBlack())
+			LYXERR0("Screen black after event(" << e->type() << ")");
 		return QAbstractScrollArea::event(e);
 	}
 
 	default:
+		if (isBlack())
+			LYXERR0("Screen black after event(" << e->type() << ")");
 		return QAbstractScrollArea::event(e);
 	}
 	return false;
@@ -1243,6 +1268,8 @@ void GuiWorkArea::paintEvent(QPaintEvent * ev)
 	if (d->caret_visible_)
 		d->caret_->draw(pain);
 	ev->accept();
+	init_done_ = true;
+
 }
 
 
diff --git a/src/frontends/qt4/GuiWorkArea.h b/src/frontends/qt4/GuiWorkArea.h
index 4fd5249..5a87976 100644
--- a/src/frontends/qt4/GuiWorkArea.h
+++ b/src/frontends/qt4/GuiWorkArea.h
@@ -151,6 +151,9 @@ private:
 	/// The slot connected to SyntheticMouseEvent::timeout.
 	void generateSyntheticMouseEvent();
 
+	bool init_done_;
+	bool isBlack();
+
 	friend class GuiCompleter;
 	struct Private;
 	Private * const d;
-- 
2.7.4

Re: LyX-Workarea: Background not shown correctly

[Jean-Marc Lasgouttes]

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.


Here is a new try, that reads the screeen and detects when the point at 
(0,0) has turned black. At least we will now if the color change happens 
inside an event handler.


JMarc


From 73db1cb163793c35092a98f43bf5b1165abd90ca Mon Sep 17 00:00:00 2001
From: Jean-Marc Lasgouttes 
Date: Wed, 4 Oct 2017 15:26:41 +0200
Subject: [PATCH] debug2

---
 src/frontends/qt4/GuiWorkArea.cpp | 29 ++---
 src/frontends/qt4/GuiWorkArea.h   |  3 +++
 2 files changed, 29 insertions(+), 3 deletions(-)

diff --git a/src/frontends/qt4/GuiWorkArea.cpp b/src/frontends/qt4/GuiWorkArea.cpp
index a24e8da..3b6ab57 100644
--- a/src/frontends/qt4/GuiWorkArea.cpp
+++ b/src/frontends/qt4/GuiWorkArea.cpp
@@ -268,13 +268,13 @@ GuiWorkArea::Private::~Private()
 
 
 GuiWorkArea::GuiWorkArea(QWidget * /* w */)
-: d(new Private(this))
+	: init_done_(false), d(new Private(this))
 {
 }
 
 
 GuiWorkArea::GuiWorkArea(Buffer & buffer, GuiView & gv)
-: d(new Private(this))
+	: init_done_(false), d(new Private(this))
 {
 	setGuiView(gv);
 	buffer.params().display_pixel_ratio = theGuiApp()->pixelRatio();
@@ -432,7 +432,7 @@ void GuiWorkArea::startBlinkingCaret()
 	d->showCaret();
 
 	//we're not supposed to cache this value.
-	int const time = QApplication::cursorFlashTime() / 2;
+	int const time = 100; //QApplication::cursorFlashTime() / 2;
 	if (time <= 0)
 		return;
 	d->caret_timeout_.setInterval(time);
@@ -684,8 +684,19 @@ void GuiWorkArea::scrollTo(int value)
 }
 
 
+bool GuiWorkArea::isBlack()
+{
+	if (!init_done_)
+		return false;
+	QImage qi = QPixmap::grabWidget(viewport(), QRect(0,0,10,10)).toImage();
+	return qi.pixel(0,0) == 0xff00;
+}
+
+
 bool GuiWorkArea::event(QEvent * e)
 {
+	if (isBlack())
+		LYXERR0("Screen black before event(" << e->type() << ")");
 	switch (e->type()) {
 	case QEvent::ToolTip: {
 		QHelpEvent * helpEvent = static_cast(e);
@@ -700,6 +711,8 @@ bool GuiWorkArea::event(QEvent * e)
 		}
 		// Don't forget to accept the event!
 		e->accept();
+		if (isBlack())
+			LYXERR0("Screen black after event(" << e->type() << ")");
 		return true;
 	}
 
@@ -707,6 +720,8 @@ bool GuiWorkArea::event(QEvent * e)
 		// keyPressEvent is ShortcutOverride-aware and only accepts the event in
 		// this case
 		keyPressEvent(static_cast(e));
+		if (isBlack())
+			LYXERR0("Screen black after event(" << e->type() << ")");
 		return e->isAccepted();
 
 	case QEvent::KeyPress: {
@@ -719,12 +734,18 @@ bool GuiWorkArea::event(QEvent * e)
 ke->modifiers() == Qt::ShiftModifier
 || ke->modifiers() == Qt::NoModifier))) {
 			keyPressEvent(ke);
+			if (isBlack())
+LYXERR0("Screen black after event(" << e->type() << ")");
 			return true;
 		}
+		if (isBlack())
+			LYXERR0("Screen black after event(" << e->type() << ")");
 		return QAbstractScrollArea::event(e);
 	}
 
 	default:
+		if (isBlack())
+			LYXERR0("Screen black after event(" << e->type() << ")");
 		return QAbstractScrollArea::event(e);
 	}
 	return false;
@@ -1243,6 +1264,8 @@ void GuiWorkArea::paintEvent(QPaintEvent * ev)
 	if (d->caret_visible_)
 		d->caret_->draw(pain);
 	ev->accept();
+	init_done_ = true;
+
 }
 
 
diff --git a/src/frontends/qt4/GuiWorkArea.h b/src/frontends/qt4/GuiWorkArea.h
index 4fd5249..5a87976 100644
--- a/src/frontends/qt4/GuiWorkArea.h
+++ b/src/frontends/qt4/GuiWorkArea.h
@@ -151,6 +151,9 @@ private:
 	/// The slot connected to SyntheticMouseEvent::timeout.
 	void generateSyntheticMouseEvent();
 
+	bool init_done_;
+	bool isBlack();
+
 	friend class GuiCompleter;
 	struct Private;
 	Private * const d;
-- 
2.7.4

Re: LyX-Workarea: Background not shown correctly

[Stephan Witt]

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 instant.
> 
> So you are sure that this happens with one of these four events. Or wrt 
> something which is not an event, of course…

Yes. I made the corresponding notes in the terminal window.

So, I’m sure the window turns black on cursor move and the
cursor move generates these four events.

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.

Stephan

Re: LyX-Workarea: Background not shown correctly

[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 instant.


So you are sure that this happens with one of these four events. Or wrt 
something which is not an event, of course...


JMarc

Re: LyX-Workarea: Background not shown correctly

[Stephan Witt]

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,
>> InputMethodQuery = 207,
>> KeyPress = 6,
>> KeyRelease = 7
>> I cannot debug this because of the focus change from LyX to Xcode.
> 
> 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.

Stephan

Re: LyX-Workarea: Background not shown correctly

[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,
InputMethodQuery = 207,
KeyPress = 6,
KeyRelease = 7

I cannot debug this because of the focus change from LyX to Xcode.


What is this focus change? can't you run outside of xcode?

JMarc

Re: LyX-Workarea: Background not shown correctly

[Stephan Witt]

> 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 'Kontroll-T 2' is overriding old binding...
>> Error: New binding for 'Kontroll-T O' is overriding old binding...
>> Error: New binding for 'Kontroll-T T' is overriding old binding...
>> Error: New binding for 'Kontroll-T X' is overriding old binding...
>> Open splash.lyx - focus out:
>> frontends/qt4/GuiWorkArea.cpp (689): handle event(68)
> 
> Can you tell me what is the point where the window turns black?
> 
> JMarc

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 focus change from LyX to Xcode.

Stephan

> 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 binding...
> Error: New binding for 'Kontroll-T T' is overriding old binding...
> Error: New binding for 'Kontroll-T X' is overriding old binding...
> Open splash.lyx - focus out:
> frontends/qt4/GuiWorkArea.cpp (689): handle event(68)
> frontends/qt4/GuiWorkArea.cpp (689): handle event(152)
> frontends/qt4/GuiWorkArea.cpp (689): handle event(109)
> frontends/qt4/GuiWorkArea.cpp (689): handle event(21)
> frontends/qt4/GuiWorkArea.cpp (689): handle event(75)
> frontends/qt4/GuiWorkArea.cpp (689): handle event(69)
> frontends/qt4/GuiWorkArea.cpp (689): handle event(69)
> frontends/qt4/GuiWorkArea.cpp (689): handle event(69)
> frontends/qt4/GuiWorkArea.cpp (689): handle event(13)
> frontends/qt4/GuiWorkArea.cpp (689): handle event(14)
> frontends/qt4/GuiWorkArea.cpp (689): handle event(17)
> frontends/qt4/GuiWorkArea.cpp (689): handle event(26)
> frontends/qt4/GuiWorkArea.cpp (689): handle event(8)
> frontends/qt4/GuiWorkArea.cpp (689): handle event(207)
> frontends/qt4/GuiWorkArea.cpp (689): handle event(74)
> frontends/qt4/GuiWorkArea.cpp (689): handle event(78)
> frontends/qt4/GuiWorkArea.cpp (689): handle event(43)
> frontends/qt4/GuiWorkArea.cpp (689): handle event(43)
> frontends/qt4/GuiWorkArea.cpp (689): handle event(43)
> frontends/qt4/GuiWorkArea.cpp (689): handle event(76)
> frontends/qt4/GuiWorkArea.cpp (689): handle event(43)
> frontends/qt4/GuiWorkArea.cpp (689): handle event(76)
> frontends/qt4/GuiWorkArea.cpp (689): handle event(23)
> frontends/qt4/GuiWorkArea.cpp (689): handle event(23)
> frontends/qt4/GuiWorkArea.cpp (689): handle event(25)
> frontends/qt4/GuiWorkArea.cpp (689): handle event(9)
> Cursor up (51, 207, 6, 7) - focus out:
> frontends/qt4/GuiWorkArea.cpp (689): handle event(8)
> frontends/qt4/GuiWorkArea.cpp (689): handle event(207)
> frontends/qt4/GuiWorkArea.cpp (689): handle event(24)
> frontends/qt4/GuiWorkArea.cpp (689): handle event(207)
> frontends/qt4/GuiWorkArea.cpp (689): handle event(51)
> frontends/qt4/GuiWorkArea.cpp (689): handle event(207)
> frontends/qt4/GuiWorkArea.cpp (689): handle event(6)
> frontends/qt4/GuiWorkArea.cpp (689): handle event(7)
> frontends/qt4/GuiWorkArea.cpp (689): handle event(23)
> frontends/qt4/GuiWorkArea.cpp (689): handle event(23)
> frontends/qt4/GuiWorkArea.cpp (689): handle event(25)
> frontends/qt4/GuiWorkArea.cpp (689): handle event(9)
> Focus in - focus out:
> frontends/qt4/GuiWorkArea.cpp (689): handle event(8)
> frontends/qt4/GuiWorkArea.cpp (689): handle event(207)
> frontends/qt4/GuiWorkArea.cpp (689): handle event(24)
> frontends/qt4/GuiWorkArea.cpp (689): handle event(207)
> frontends/qt4/GuiWorkArea.cpp (689): handle event(23)
> frontends/qt4/GuiWorkArea.cpp (689): handle event(23)
> frontends/qt4/GuiWorkArea.cpp (689): handle event(25)
> frontends/qt4/GuiWorkArea.cpp (689): handle event(9)
> Focus in - Cursor up - focus out:
> frontends/qt4/GuiWorkArea.cpp (689): handle event(8)
> frontends/qt4/GuiWorkArea.cpp (689): handle event(207)
> frontends/qt4/GuiWorkArea.cpp (689): handle event(24)
> frontends/qt4/GuiWorkArea.cpp (689): handle event(207)
> frontends/qt4/GuiWorkArea.cpp (689): handle event(51)
> frontends/qt4/GuiWorkArea.cpp (689): handle event(207)
> frontends/qt4/GuiWorkArea.cpp (689): handle event(6)
> frontends/qt4/GuiWorkArea.cpp (689): handle event(7)
> frontends/qt4/GuiWorkArea.cpp (689): handle event(23)
> frontends/qt4/GuiWorkArea.cpp (689): handle event(23)
> frontends/qt4/GuiWorkArea.cpp (689): handle event(25)
> frontends/qt4/GuiWorkArea.cpp (689): handle event(9)

Re: LyX-Workarea: Background not shown correctly

[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 'Kontroll-T 2' is overriding old binding...
Error: New binding for 'Kontroll-T O' is overriding old binding...
Error: New binding for 'Kontroll-T T' is overriding old binding...
Error: New binding for 'Kontroll-T X' is overriding old binding...
Open splash.lyx - focus out:
frontends/qt4/GuiWorkArea.cpp (689): handle event(68)


Can you tell me what is the point where the window turns black?

JMarc

Re: LyX-Workarea: Background not shown correctly

[Stephan Witt]

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 out. We have to find a way to detect these cases.
> 
> Could you try the following debug patch? It prints out the code of all events 
> the GuiWordArea::event() sees. I also removed the cursor blinking to reduce 
> the number of events.
> 
> Could you send me the events that get printed on console at the moment where 
> the screen turns black?
> 
> JMarc
> <0001-debug.patch>

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 binding...
Error: New binding for 'Kontroll-T T' is overriding old binding...
Error: New binding for 'Kontroll-T X' is overriding old binding...
Open splash.lyx - focus out:
frontends/qt4/GuiWorkArea.cpp (689): handle event(68)
frontends/qt4/GuiWorkArea.cpp (689): handle event(152)
frontends/qt4/GuiWorkArea.cpp (689): handle event(109)
frontends/qt4/GuiWorkArea.cpp (689): handle event(21)
frontends/qt4/GuiWorkArea.cpp (689): handle event(75)
frontends/qt4/GuiWorkArea.cpp (689): handle event(69)
frontends/qt4/GuiWorkArea.cpp (689): handle event(69)
frontends/qt4/GuiWorkArea.cpp (689): handle event(69)
frontends/qt4/GuiWorkArea.cpp (689): handle event(13)
frontends/qt4/GuiWorkArea.cpp (689): handle event(14)
frontends/qt4/GuiWorkArea.cpp (689): handle event(17)
frontends/qt4/GuiWorkArea.cpp (689): handle event(26)
frontends/qt4/GuiWorkArea.cpp (689): handle event(8)
frontends/qt4/GuiWorkArea.cpp (689): handle event(207)
frontends/qt4/GuiWorkArea.cpp (689): handle event(74)
frontends/qt4/GuiWorkArea.cpp (689): handle event(78)
frontends/qt4/GuiWorkArea.cpp (689): handle event(43)
frontends/qt4/GuiWorkArea.cpp (689): handle event(43)
frontends/qt4/GuiWorkArea.cpp (689): handle event(43)
frontends/qt4/GuiWorkArea.cpp (689): handle event(76)
frontends/qt4/GuiWorkArea.cpp (689): handle event(43)
frontends/qt4/GuiWorkArea.cpp (689): handle event(76)
frontends/qt4/GuiWorkArea.cpp (689): handle event(23)
frontends/qt4/GuiWorkArea.cpp (689): handle event(23)
frontends/qt4/GuiWorkArea.cpp (689): handle event(25)
frontends/qt4/GuiWorkArea.cpp (689): handle event(9)
Cursor up (51, 207, 6, 7) - focus out:
frontends/qt4/GuiWorkArea.cpp (689): handle event(8)
frontends/qt4/GuiWorkArea.cpp (689): handle event(207)
frontends/qt4/GuiWorkArea.cpp (689): handle event(24)
frontends/qt4/GuiWorkArea.cpp (689): handle event(207)
frontends/qt4/GuiWorkArea.cpp (689): handle event(51)
frontends/qt4/GuiWorkArea.cpp (689): handle event(207)
frontends/qt4/GuiWorkArea.cpp (689): handle event(6)
frontends/qt4/GuiWorkArea.cpp (689): handle event(7)
frontends/qt4/GuiWorkArea.cpp (689): handle event(23)
frontends/qt4/GuiWorkArea.cpp (689): handle event(23)
frontends/qt4/GuiWorkArea.cpp (689): handle event(25)
frontends/qt4/GuiWorkArea.cpp (689): handle event(9)
Focus in - focus out:
frontends/qt4/GuiWorkArea.cpp (689): handle event(8)
frontends/qt4/GuiWorkArea.cpp (689): handle event(207)
frontends/qt4/GuiWorkArea.cpp (689): handle event(24)
frontends/qt4/GuiWorkArea.cpp (689): handle event(207)
frontends/qt4/GuiWorkArea.cpp (689): handle event(23)
frontends/qt4/GuiWorkArea.cpp (689): handle event(23)
frontends/qt4/GuiWorkArea.cpp (689): handle event(25)
frontends/qt4/GuiWorkArea.cpp (689): handle event(9)
Focus in - Cursor up - focus out:
frontends/qt4/GuiWorkArea.cpp (689): handle event(8)
frontends/qt4/GuiWorkArea.cpp (689): handle event(207)
frontends/qt4/GuiWorkArea.cpp (689): handle event(24)
frontends/qt4/GuiWorkArea.cpp (689): handle event(207)
frontends/qt4/GuiWorkArea.cpp (689): handle event(51)
frontends/qt4/GuiWorkArea.cpp (689): handle event(207)
frontends/qt4/GuiWorkArea.cpp (689): handle event(6)
frontends/qt4/GuiWorkArea.cpp (689): handle event(7)
frontends/qt4/GuiWorkArea.cpp (689): handle event(23)
frontends/qt4/GuiWorkArea.cpp (689): handle event(23)
frontends/qt4/GuiWorkArea.cpp (689): handle event(25)
frontends/qt4/GuiWorkArea.cpp (689): handle event(9)

HTH,
Stephan

Re: LyX-Workarea: Background not shown correctly

[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 out. We have to find a way to detect these cases.


Could you try the following debug patch? It prints out the code of all 
events the GuiWordArea::event() sees. I also removed the cursor blinking 
to reduce the number of events.


Could you send me the events that get printed on console at the moment 
where the screen turns black?


JMarc
From 5c11808643ae58b790cf38b3b5ba2d62194f95fa Mon Sep 17 00:00:00 2001
From: Jean-Marc Lasgouttes 
Date: Wed, 4 Oct 2017 15:26:41 +0200
Subject: [PATCH] debug

---
 src/frontends/qt4/GuiWorkArea.cpp | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/frontends/qt4/GuiWorkArea.cpp b/src/frontends/qt4/GuiWorkArea.cpp
index 36dd253..25114eb 100644
--- a/src/frontends/qt4/GuiWorkArea.cpp
+++ b/src/frontends/qt4/GuiWorkArea.cpp
@@ -242,7 +242,7 @@ GuiWorkArea::Private::Private(GuiWorkArea * parent)
   completer_(new GuiCompleter(p, p)), dialog_mode_(false), shell_escape_(false),
   read_only_(false), clean_(true), externally_modified_(false)
 {
-	int const time = QApplication::cursorFlashTime() / 2;
+	int const time = 100; //QApplication::cursorFlashTime() / 2;
 	if (time > 0) {
 		caret_timeout_.setInterval(time);
 		caret_timeout_.start();
@@ -683,6 +683,7 @@ void GuiWorkArea::scrollTo(int value)
 
 bool GuiWorkArea::event(QEvent * e)
 {
+	LYXERR0("handle event(" << e->type() << ")");
 	switch (e->type()) {
 	case QEvent::ToolTip: {
 		QHelpEvent * helpEvent = static_cast(e);
-- 
2.7.4

Re: LyX-Workarea: Background not shown correctly

[Jean-Marc Lasgouttes]

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 and cursor movements
force the repaint of small areas. After resize the work area is
correctly displayed again.

It’s „better“ with Qt4 but not good.


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.


JMarc

Re: LyX-Workarea: Background not shown correctly

[Stephan Witt]

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 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 QBackingStore class). Does this means that Qt5 handling 
>> should be different from Qt4 one?
> 
> Sorry, I don’t know what I’ve talked about. It was a wild guess.
> I know with X11 there is an option to have the backing store
> at X-Server-side to reduce the network traffic. But I don’t
> know if and how it is used by Qt and if there are pitfalls or
> bugs on Mac with it.
> 
>> Can you still compile with qt4? If yes, is the bug present there too?
> 
> 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 and cursor movements
force the repaint of small areas. After resize the work area is
correctly displayed again.

It’s „better“ with Qt4 but not good.

Stephan

Re: LyX-Workarea: Background not shown correctly

[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 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 QBackingStore class). Does this means that Qt5 handling should be 
> different from Qt4 one?

Sorry, I don’t know what I’ve talked about. It was a wild guess.
I know with X11 there is an option to have the backing store
at X-Server-side to reduce the network traffic. But I don’t
know if and how it is used by Qt and if there are pitfalls or
bugs on Mac with it.

> Can you still compile with qt4? If yes, is the bug present there too?

Yes, I’ve built it with Qt4 now and no, the bug isn’t present there.

Stephan

Re: LyX-Workarea: Background not shown correctly

[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. The Qt4 doc mentions it, but only Qt5 has means to 
interact with it (and a QBackingStore class). Does this means that Qt5 
handling should be different from Qt4 one?


Can you still compile with qt4? If yes, is the bug present there too?

JMarc

Re: LyX-Workarea: Background not shown correctly

[Stephan Witt]

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 correctly when it is covered by 
> another one?

No, that’s not the problem. It looks like a problem with the „backing store“.
After a resize the work area is shown ok. The cursor movement turns most of
it into black. When the cursor reaches the bottom of the window and the contents
gets scrolled it is ok again - because of the full redraw probably. Moving the
cursor one line up the black screen is back.

The pdflatex run is not the problem. It has the same affect as the cursor down
without the cursor movement - so the whole work area is black. No redraw is
required but the restore of the painted contents does not work, AFAICS.

ATM, I have not enough time to make the screencast, sorry.

Stephan

Re: LyX-Workarea: Background not shown correctly

[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 correctly when it is covered 
by another one?


JMarc

Re: LyX-Workarea: Background not shown correctly

[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.


I suspect I am missing something. I do not see how running view pdflatex 
may interfere? A screencast, maybe?


JMarc

Re: LyX-Workarea: Background not shown correctly

[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.


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.


JMarc

Re: LyX-Workarea: Background not shown correctly

[Stephan Witt]

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" debug flag tell us?

==
Setting debug level to painting
Debugging `painting' (RowPainter profiling)
BufferView.cpp (2719): metrics:  anchor pit = 0 anchor ypos = 43
BufferView.cpp (2755): Metrics:  anchor pit = 0 anchor ypos = 43 y1 = 0 y2 = 
492 pit1 = -1 pit2 = 8
BufferView.cpp (3066):  *** START DRAWING ***
BufferView.cpp (3123): Strategy: FullScreenUpdate
BufferView.cpp (3146): 
*** END DRAWING  ***
BufferView.cpp (3163): Found new anchor pit = 0  anchor ypos = 43
BufferView.cpp (2719): metrics:  anchor pit = 0 anchor ypos = 43
BufferView.cpp (2755): Metrics:  anchor pit = 0 anchor ypos = 43 y1 = 0 y2 = 
492 pit1 = -1 pit2 = 8
BufferView.cpp (3066):  *** START DRAWING ***
BufferView.cpp (3123): Strategy: FullScreenUpdate
BufferView.cpp (3146): 
*** END DRAWING  ***
BufferView.cpp (3163): Found new anchor pit = 0  anchor ypos = 43
BufferView.cpp (2719): metrics:  anchor pit = 0 anchor ypos = 43
BufferView.cpp (2755): Metrics:  anchor pit = 0 anchor ypos = 43 y1 = 0 y2 = 
492 pit1 = -1 pit2 = 8
BufferView.cpp (3066):  *** START DRAWING ***
BufferView.cpp (3123): Strategy: FullScreenUpdate
BufferView.cpp (3146): 
*** END DRAWING  ***
BufferView.cpp (3163): Found new anchor pit = 0  anchor ypos = 43
BufferView.cpp (2719): metrics:  anchor pit = 0 anchor ypos = 43
BufferView.cpp (2755): Metrics:  anchor pit = 0 anchor ypos = 43 y1 = 0 y2 = 
446 pit1 = -1 pit2 = 7
BufferView.cpp (3066):  *** START DRAWING ***
BufferView.cpp (3123): Strategy: FullScreenUpdate
BufferView.cpp (3146): 
*** END DRAWING  ***
BufferView.cpp (3163): Found new anchor pit = 0  anchor ypos = 43
BufferView.cpp (3066):  *** START DRAWING ***
BufferView.cpp (3123): Strategy: FullScreenUpdate
TextMetrics.cpp (1938): main text redraw pit=0 row=0 row_selection=0 
full_repaint=1 row_has_changed=1 null painter=0
TextMetrics.cpp (1938): main text redraw pit=1 row=0 row_selection=0 
full_repaint=1 row_has_changed=1 null painter=0
TextMetrics.cpp (1938): main text redraw pit=2 row=0 row_selection=0 
full_repaint=1 row_has_changed=1 null painter=0
TextMetrics.cpp (1938): main text redraw pit=2 row=1 row_selection=0 
full_repaint=1 row_has_changed=1 null painter=0
TextMetrics.cpp (1938): main text redraw pit=2 row=2 row_selection=0 
full_repaint=1 row_has_changed=1 null painter=0
TextMetrics.cpp (1938): main text redraw pit=3 row=0 row_selection=0 
full_repaint=1 row_has_changed=1 null painter=0
TextMetrics.cpp (1938): main text redraw pit=3 row=1 row_selection=0 
full_repaint=1 row_has_changed=1 null painter=0
TextMetrics.cpp (1938): main text redraw pit=3 row=2 row_selection=0 
full_repaint=1 row_has_changed=1 null painter=0
TextMetrics.cpp (1938): main text redraw pit=4 row=0 row_selection=0 
full_repaint=1 row_has_changed=1 null painter=0
TextMetrics.cpp (1938): main text redraw pit=4 row=1 row_selection=0 
full_repaint=1 row_has_changed=1 null painter=0
TextMetrics.cpp (1938): inset text redraw: pit=0 row=0 row_selection=0 
full_repaint=1 row_has_changed=1 null painter=0
TextMetrics.cpp (1938): main text redraw pit=5 row=0 row_selection=0 
full_repaint=1 row_has_changed=1 null painter=0
TextMetrics.cpp (1938): main text redraw pit=5 row=1 row_selection=0 
full_repaint=1 row_has_changed=1 null painter=0
TextMetrics.cpp (1938): main text redraw pit=5 row=2 row_selection=0 
full_repaint=1 row_has_changed=1 null painter=0
TextMetrics.cpp (1938): main text redraw pit=6 row=0 row_selection=0 
full_repaint=1 row_has_changed=1 null painter=0
TextMetrics.cpp (1938): main text redraw pit=6 row=1 row_selection=0 
full_repaint=1 row_has_changed=1 null painter=0
BufferView.cpp (3146): 
*** END DRAWING  ***
BufferView.cpp (3163): Found new anchor pit = 0  anchor ypos = 43
BufferView.cpp (455): BufferView::processUpdateFlags()[fitcursor = 1, 
forceupdate = 0, singlepar = 0]  buffer: 0x15391e660
BufferView.cpp (3066):  *** START DRAWING ***
BufferView.cpp (3093): Strategy: NoScreenUpdate
BufferView.cpp (3146): 
*** END DRAWING  ***
BufferView.cpp (3163): Found new anchor pit = 0  anchor ypos = 43
BufferView.cpp (3066):  *** START DRAWING ***
BufferView.cpp (3093): Strategy: NoScreenUpdate
BufferView.cpp (3146): 
*** END DRAWING  ***
BufferView.cpp (3163): Found new anchor pit = 0  anchor ypos = 43
BufferView.cpp (3066):  *** START DRAWING ***
BufferView.cpp (3093): Strategy: NoScreenUpdate
BufferView.cpp (3146): 
*** END DRAWING  ***
BufferView.cpp (3163): Found new anchor pit = 0  anchor ypos = 43
BufferView.cpp (3066):  *** START DRAWING ***
BufferView.cpp 

Re: LyX-Workarea: Background not shown correctly

[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" debug flag tell us?

JMarc

Re: LyX-Workarea: Background not shown correctly

[Stephan Witt]

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 
> at all.
> 
> Can you try the following? I had removed these calls but I am not sure what 
> they were good for. You could also try to remove the
>  viewport()->setAttribute(Qt::WA_OpaquePaintEvent);

The patch makes no difference again, sorry. Removing the mentioned line changes 
it to gray background.

Stephan

Screen-shot after line-down key press.

Re: LyX-Workarea: Background not shown correctly

[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 at all.


Can you try the following? I had removed these calls but I am not sure 
what they were good for. You could also try to remove the

  viewport()->setAttribute(Qt::WA_OpaquePaintEvent);

JMarc
diff --git a/src/frontends/qt4/GuiWorkArea.cpp b/src/frontends/qt4/GuiWorkArea.cpp
index 36dd253..c4e71da 100644
--- a/src/frontends/qt4/GuiWorkArea.cpp
+++ b/src/frontends/qt4/GuiWorkArea.cpp
@@ -318,6 +318,8 @@ void GuiWorkArea::init()
 
 	d->updateCursorShape();
 
+	viewport()->setAutoFillBackground(false);
+	viewport()->setAttribute(Qt::WA_NoSystemBackground);
 	// we paint our own background
 	viewport()->setAttribute(Qt::WA_OpaquePaintEvent);
 

Re: LyX-Workarea: Background not shown correctly

[Stephan Witt]

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 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?
>> Some uninitialized variable perhaps?
>> The same happens from the beginning when the opened document is shorter
>> than the viewport size. The work area is completely black then. If I click
>> somewhere it get’s painted normally.
> 
> Can you try this patch?

Doesn’t help, sorry.

Perhaps the black screen is „painted“ by the null painter?

Stephan

Re: LyX-Workarea: Background not shown correctly

[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 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?


Some uninitialized variable perhaps?

The same happens from the beginning when the opened document is shorter
than the viewport size. The work area is completely black then. If I click
somewhere it get’s painted normally.


Can you try this patch?

JMarc


diff --git a/src/BufferView.cpp b/src/BufferView.cpp
index ab264ba..7b41016 100644
--- a/src/BufferView.cpp
+++ b/src/BufferView.cpp
@@ -228,7 +228,7 @@ enum ScreenUpdateStrategy {
 
 struct BufferView::Private
 {
-	Private(BufferView & bv) : update_strategy_(NoScreenUpdate),
+	Private(BufferView & bv) : update_strategy_(FullScreenUpdate),
 		wh_(0), cursor_(bv),
 		anchor_pit_(0), anchor_ypos_(0),
 		inlineCompletionUniqueChars_(0),

Re: LyX-Workarea: Background not shown correctly

[Jean-Marc Lasgouttes]

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 strategy.


JMarc

Re: LyX-Workarea: Background not shown correctly

[Stephan Witt]

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 still see this issue after the last pair of fixes?

Yes, unfortunately.

If I can debug it for you - a hint would be useful.

Stephan

Re: LyX-Workarea: Background not shown correctly

[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 still see this issue after the last pair of fixes?

JMarc

Re: LyX-Workarea: Background not shown correctly

[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 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?


Some uninitialized variable perhaps?


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.


JMarc

Re: LyX-Workarea: Background not shown correctly

[Stephan Witt]

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 thought. Where does all this black come 
> from?

Some uninitialized variable perhaps?

The same happens from the beginning when the opened document is shorter
than the viewport size. The work area is completely black then. If I click
somewhere it get’s painted normally.

Stephan

Re: LyX-Workarea: Background not shown correctly

[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 thought. Where does all this black 
come from?


JMarc