This shows the problem:
BR, Tom

Thinking about it, I have suspiction that maybe RawPickToValue might have to do something with all that...

What about this:

struct sMakeGlyph : LRUCache<String, GlyphKey>::Maker {
	GlyphKey gk;

	GlyphKey Key() const     { return gk; }
	int      Make(String& v) const {
		GlyphPainter gp;
		gp.move = gp.pos = Null;
		gp.tolerance = gk.tolerance;
		PaintCharacter(gp, Pointf(0, 0), gk.chr, gk.fnt);
		int sz = gp.glyph.GetCount() * 4;
		v.Set((char *)gp.glyph.begin(), sizeof(float) * gp.glyph.GetCount());
		return sz;
	}
};

void ApproximateChar(LinearPathConsumer& t, Pointf at, int ch, Font fnt, double tolerance)
{
	PAINTER_TIMING("ApproximateChar");
	String v;
	INTERLOCKED {
		PAINTER_TIMING("ApproximateChar::Fetch");
		static LRUCache<String, GlyphKey> cache;
		cache.Shrink(500000);
		sMakeGlyph h;
		h.gk.fnt = fnt;
		h.gk.chr = ch;
		h.gk.tolerance = tolerance;
		v = cache.Get(h);
	}
	int i = 0;
	int count = v.GetCount() / sizeof(float);
	const float *g = (const float *)~v;
	while(i < count) {
		Pointf p;
		p.x = g[i++];
		if(p.x > 1e30) {
			p.x = g[i++];
			p.y = g[i++];
			t.Move(p + at);
		}
		else {
			PAINTER_TIMING("ApproximateChar::Line");
			p.y = g[i++];
			t.Line(p + at);
		}
	}
}

Have you tried this on another computer? (Blaming HW is the last thing I usually do, but this is way too weird...)

Mirek

According to Windows Task Manager, there are 30 threads running on this process. But my GUI is simply running on main thread. There should be nothing graphical going on in any of my background threads.

Here's an interesting part: I said previously that ST/MT in Painter did not make any difference. Well, it did not when I had started the program originally with Painter MT enabled and then switched 'live' to ST to test for the error effect. BUT: Now I started with Painter fixed in ST and: Error is gone... Sounds like in my original MT/ST test the font caching in Painter had already happened in MT before I switched it to ST.

I need to dig deeper on this.

BR, Tom

Have you tried this on another computer? (Blaming HW is the last thing I usually do, but this is way too weird...)

Mirek

Try this pls:

Buffer<ClippingLine> BufferPainter::RenderPath(double width, Event<One<SpanSource>&> ss, const RGBA& color)
{
	PAINTER_TIMING("RenderPath");
	Buffer<ClippingLine> newclip;

	if(width == FILL)
		Close();

	current = Null;

	if(width == 0 || !ss && color.a == 0 && width >= FILL)
		return newclip;
	
	if(pathattr.mtx_serial != preclip_mtx_serial) {
		if(dopreclip) {
			Pointf tl, br, a;
			Xform2D imx = Inverse(pathattr.mtx);
			tl = br = imx.Transform(0, 0);
			a = imx.Transform(size.cx, 0);
			tl = min(a, tl);
			br = max(a, br);
			a = imx.Transform(0, size.cy);
			tl = min(a, tl);
			br = max(a, br);
			a = imx.Transform(size.cx, size.cy);
			tl = min(a, tl);
			br = max(a, br);
			preclip = Rectf(tl, br);
		}
		else
			preclip = Null;
		regular = pathattr.mtx.IsRegular();
		preclip_mtx_serial = pathattr.mtx_serial;
	}

	if(co) {
		if(width >= FILL && !ss && !alt && findarg(mode, MODE_ANTIALIASED, MODE_SUBPIXEL) >= 0 && !path_info->ischar) {

(The difference is && !path_info->ischar in the last line).

Also, is there a difference DEBUG vs RELEASE?

Not a single false character in DEBUG mode either.

I should have found something already if the problem still existed.

So, is this the fix or means for problem isolation?

Best regards,

Tom

void Painter::TextOp(const Pointf& p, const wchar *text, Font fnt, int n, const double *dx)
{
	if(n == 0) {
		Move(0, 0);
		return;
	}
	FontInfo fi = fnt.Info();
	double x = p.x;
	while(n) {
		int ch = *text++;
		Character(x, p.y, ch, fnt);
//		Div();
		if(dx)
			x += *dx++;
		else
			x += fi[ch];
		n--;
	}
	if(fnt.IsUnderline() || fnt.IsStrikeout()) {
		double a = fnt.GetAscent();
		double cy = max(a / 16, 1.0);
		double cx = x - p.x;
		if(fnt.IsUnderline())
			Rectangle(p.x, p.y + a + cy, cx, cy);
		if(fnt.IsStrikeout())
			Rectangle(p.x, p.y + 2 * a / 3, cx, cy);
	}
}

void BufferPainter::RenderPathSegments(LinearPathConsumer *g, const Vector<byte>& path,
                                       const SimpleAttr *attr, double tolerance)
{
	Pointf pos = Pointf(0, 0);
	const byte *data = path.begin();
	const byte *end = path.end();
	while(data < end) {
		const LinearData *d = (LinearData *)data;
		switch(d->type) {
		case MOVE: {
			g->Move(pos = attr ? attr->mtx.Transform(d->p) : d->p);
			data += sizeof(LinearData);
			break;
		}
		case LINE: {
			PAINTER_TIMING("LINE");
			g->Line(pos = attr ? attr->mtx.Transform(d->p) : d->p);
			data += sizeof(LinearData);
			break;
		}
		case QUADRATIC: {
			PAINTER_TIMING("QUADRATIC");
			const QuadraticData *d = (QuadraticData *)data;
			if(attr) {
				Pointf p = attr->mtx.Transform(d->p);
				ApproximateQuadratic(*g, pos, attr->mtx.Transform(d->p1), p, tolerance);
				pos = p;
			}
			else {
				ApproximateQuadratic(*g, pos, d->p1, d->p, tolerance);
				pos = d->p;
			}
			data += sizeof(QuadraticData);
			break;
		}
		case CUBIC: {
			PAINTER_TIMING("CUBIC");
			const CubicData *d = (CubicData *)data;
			if(attr) {
				Pointf p = attr->mtx.Transform(d->p);
				ApproximateCubic(*g, pos, attr->mtx.Transform(d->p1),
				                 attr->mtx.Transform(d->p2), p, tolerance);
				pos = p;
			}
			else {
				ApproximateCubic(*g, pos, d->p1, d->p2, d->p, tolerance);
				pos = d->p;
			}
			data += sizeof(CubicData);
			break;
		}
		case CHAR: {
			const CharData *ch = (CharData *)data;
			INTERLOCKED ApproximateChar(*g, ch->p, ch->ch, ch->fnt, tolerance);
			data += sizeof(CharData);
			break;
		}
		default:
			NEVER();
			g->End();
			return;
		}
	}
	g->End();
}

No, false positive. The problem is still there even after the "void Painter::TextOp(const Pointf& p, const wchar *text, Font fnt, int n, const double *dx)" -fix.

BR, Tom

One potential reason for finding this issue is that I had just recently reached a point in my own code where I started to rotate the texts according to the original scale and rotation, both of which change constantly over the projection surface for maps where a change from one map projection to another has been carried out.

In effect this has caused an overwhelming increase in cached fonts here in my application.

Tom1 wrote on Mon, 14 January 2019 17:21

One potential reason for finding this issue is that I had just recently reached a point in my own code where I started to rotate the texts according to the original scale and rotation, both of which change constantly over the projection surface for maps where a change from one map projection to another has been carried out.

In effect this has caused an overwhelming increase in cached fonts here in my application.

Rotated texts in Painter are rotated by Painter matrix, they are cached in zero angle position...

Anyway, good info, I will think about this all...

Mirek

mirek wrote on Mon, 14 January 2019 18:45

Tom1 wrote on Mon, 14 January 2019 17:21

One potential reason for finding this issue is that I had just recently reached a point in my own code where I started to rotate the texts according to the original scale and rotation, both of which change constantly over the projection surface for maps where a change from one map projection to another has been carried out.

In effect this has caused an overwhelming increase in cached fonts here in my application.

Rotated texts in Painter are rotated by Painter matrix, they are cached in zero angle position...

Anyway, good info, I will think about this all...

Mirek

Well, yes, they are indeed cached in zero angle position. I should have expressed myself more clearly to make the point: Both fine scaling and fine rotation changes ultimately have an effect on double tolerance value solved using the Painter matrix scale and stored as caching key. This is also why rotating the image sometimes corrected the problem. Please see my early screenshots in this thread. (The changes would have been just at a magnitude of rounding errors i.e. just some LSBs.)

BR, Tom

OK, now I see possible bug, hard to say it is related, but please test:

void BufferPainter::FinishPathJob()
{
	if(jobcount == 0)
		return;
	{
		CoWork co;
		co * [&] {
			for(;;) {
				int i = co.Next();
				if(i >= jobcount)
					break;
				CoJob& b = cojob[i];
				b.rasterizer.Reset();
				PathJob j(b.rasterizer, b.width, b.path_info, b.attr, b.preclip, b.regular);
				if(!j.preclipped) {
					b.evenodd = j.evenodd;
					BufferPainter::RenderPathSegments(j.g, b.path_info->path[b.subpath], j.regular ? &b.attr : NULL, j.tolerance);
				}
			}
		};
	}

	FinishFillJob();

(The difference is that CoWork is now inside block).

EDIT: Perhaps check the possible fix first - the last post "OK, now I see possible bug, hard to say it is related, but please test:" and do testing only if it fails.

To test:

void BufferPainter::FinishPathJob()
{
	if(jobcount == 0)
		return;
/*	CoWork co;
	co * [&] {
		for(;;) {
			int i = co.Next();
			if(i >= jobcount)
				break;
			CoJob& b = cojob[i];
			b.rasterizer.Reset();
			PathJob j(b.rasterizer, b.width, b.path_info, b.attr, b.preclip, b.regular);
			if(!j.preclipped) {
				b.evenodd = j.evenodd;
				BufferPainter::RenderPathSegments(j.g, b.path_info->path[b.subpath], j.regular ? &b.attr : NULL, j.tolerance);
			}
		}
	};*/
	for(int i = 0; i < jobcount; i++) {
		CoJob& b = cojob[i];
		b.rasterizer.Reset();
		PathJob j(b.rasterizer, b.width, b.path_info, b.attr, b.preclip, b.regular);
		if(!j.preclipped) {
			b.evenodd = j.evenodd;
			BufferPainter::RenderPathSegments(j.g, b.path_info->path[b.subpath], j.regular ? &b.attr : NULL, j.tolerance);
		}
	}

	FinishFillJob();
	
	fillcount = jobcount;
	Swap(cofill, cojob); // Swap to keep allocated rasters (instead of pick)

(Changing the path rendering to run in ST)

I do not know if this has anything to do with it, but I have noticed that I cannot pass reference variables as parameters to CoWork::Do() -called functions. Compiler does not complain, but the code simply does not work correctly. I have had to switch to using pointers as parameters instead of reference variables in such functions.

Hi,

As for forcing "tolerance = 0.3;" likely decreases the number of cache entries to a fraction of the original in this case, the likelihood to see any issues drops equally. And so it seems: I cannot see a single erroneous character.

Then again, I can check about 1000 names in a reasonable time on screen and if the problem is there, I will see just a few errors. I think that it becomes just a few errors in a million now, so I'm not 'lucky enough' to find them.

BR, Tom

Tom1 wrote on Tue, 15 January 2019 08:53

I do not know if this has anything to do with it, but I have noticed that I cannot pass reference variables as parameters to CoWork::Do() -called functions. Compiler does not complain, but the code simply does not work correctly. I have had to switch to using pointers as parameters instead of reference variables in such functions.

That should not be issue here. Now all depends on details, but you always have to be careful that referenced variable exists until CoWork Finish or destructor... If you think that you have non-working example of different nature, please start a new thread a post it...

Mirek

void BufferPainter::FinishPathJob()
{
	if(jobcount == 0)
		return;

	CoWork co;
	co * [&] {
		for(;;) {
			int i = co.Next();
			if(i >= jobcount)
				break;
			INTERLOCKED {
			CoJob& b = cojob[i];
			b.rasterizer.Reset();
			PathJob j(b.rasterizer, b.width, b.path_info, b.attr, b.preclip, b.regular);
			if(!j.preclipped) {
				b.evenodd = j.evenodd;
				BufferPainter::RenderPathSegments(j.g, b.path_info->path[b.subpath], j.regular ? &b.attr : NULL, j.tolerance);
			}
			}
		}
	};

If problem disappears, try to move INTERLOCKED down line by line (until if) to see when/if it reappears.

I am also trying to reproduce the issue here; anyway the paintings I have here only has a couple o texts in it.

Now I am not sure you have any level-of-detail systeme there, but if not, would it be possible to send me extremely zoomed out painting file so that it has more texts in it?

(That said, when testing, do you start with such zoomed-out situation?)

What about locking the whole lambda body?

Also to test in the same loop:

PathJob j(b.rasterizer, b.width, b.path_info, b.attr, b.preclip, false);

(change the last parameter to 'false')

void BufferPainter::FinishPathJob()
{
	if(jobcount == 0)
		return;

	CoWork co;
	co * [&] {
		INTERLOCKED {
		for(;;) {
			int i = co.Next();
			if(i >= jobcount)
				break;
			CoJob& b = cojob[i];
			b.rasterizer.Reset();
			PathJob j(b.rasterizer, b.width, b.path_info, b.attr, b.preclip, b.regular);
			if(!j.preclipped) {
				b.evenodd = j.evenodd;
				BufferPainter::RenderPathSegments(j.g, b.path_info->path[b.subpath], j.regular ? &b.attr : NULL, j.tolerance);
			}
		}
		}
	};

What about locking the whole lambda body?

Also to test in the same loop:

PathJob j(b.rasterizer, b.width, b.path_info, b.attr, b.preclip, false);

(change the last parameter to 'false')