DDigit v1.06 Text Rendering Pack For Plugin Writers, 30 Mar 2015

[StainlessS]

EDIT: Cannot rename the thread title when thread reaches a certain age.

DDigitTest dll's For Avisynth v2.58, v2.60/+ x86 and x64.
Requires VS2008 CPP Runtimes.

(For Standard v2.60 colorspaces only).

Excerpt from DDigit.txt

DDigit Plugin Text Rendering Pack for Plugin writers.

// DDIGIT @ http://forum.doom9.org/showthread.php?t=156888


First  Release 17 Sept  2010, Wrongly Date named DDigit_25_dll_20101017
Second Release v1.0, 26 Sept  2010,  DDigitTest_25_dll_20100926
Third  Release v1.01, 6  March 2011.  DDigitTest_25_dll_20110306
	Speeded up YV12 somewhat, by thieving some of the mods from New Info.H.
	Added control code parsing for formatting and color selection within print string.
        Simplified the multiply by 7/8 on YUV background pixels, reduction of one subtract operation.
Fourth  v1.02, Release 11 March 2011.  DDigitTest_25_dll_20110311
        Fix dshift bug introduced in v1.01 Planar.
Fifth Release v1.03, 2nd June 2011.  DDigitTest_25_dll_20110602
	Adopted a 'new name' for the ColorSpace Independant Renderer in DDigit, new name being
	"DDigit MONOLITHIC".
	Added 'DDigit DISCRETE', NEW ColorSpace Dependant Renderers.
	DDigit DISCRETE, has all the functionality of DDigit MONOLITHIC with the exception
	of the vertical print functions.
	Added DDigit DISCRETE to the DDigitTest() demo plugin.
	Now using modified Info.h of April 2011.
	Added unmodified Info.h together with an Info.h companion, InfoF.h which compliments
	Info.h with formatted print via embedded control codes (see demo).
Sixth release v1.04,  20th Apr 2013, 
        Background multiplier now selectable, via define DDIGIT_BACKGROUNDFADE in header.
	Options: mult by 7/8, 3/4 5/8, or 1/2 or OPAQUE BLACK background.
	Added compile for v2.6 plugin stuff.
v1.05, 05 June 2013. Extended CMAP to 32. YV411 Luma ONLY. New color control codes added.
   '\a', Color selection control code. Followed by any one of '0123456789ABCDEFGHIJKLMNOPQRSTUV-!*'.
         0 -> V select the colors 0 -> 31. (lower case also allowed).
         '-' selects DDIGIT_DEFAULT.
         '!' selects DDIGIT_HILITE.
         '*' selects the on entry color.
v1.06,  10 July 2013, Added Length Arg.
    Switched ON YV411 chroma render, although looks better luma only (uncomment #define DDIGIT_SKIP_YV411_CHROMA)
v1.06, 30 Mar 2015. Recompile DDigitTest with Avisynth Version 6 Header.
02 Jan 2018. Moved to VS2008, added Version resource. Add x64.


------------------------------------------------------------------------------------------

	DDigit comprises of DDigit.h, and DDigit.cpp which implement a colorspace independant
	text renderer (DDigit MONOLITHIC) and a colorspace dependant set of renderers
	(DDigit DISCRETE).  DDigit is based on the source Info.h from the Avisynth project,
	but provides printing in both horizontal and vertical, pixel or character coordinates
	and in 16 colors + 16 greyscale levels.
	The renderers support embedded control codes to provide both formatting
	and color selection, within print strings. The renderers are bounds aware and will not
	crash if text wraps off screen. Both the MONOLITHIC and DISCRETE renderers provide means
	to disable unused colorspace code and also allow selection of the full font for characters
	above 127 or you can save 4KB by disabling half of the font. Most of the options of
	DDigit are switch off-able, even the ability to parse control codes in strings, disabling
	these options will result in a reduction of code size. There is pretty much zero reason
	to edit out any source code, so if anyone decides to grab a copy from your plugin source,
	they should have the complete source files. 

	DDigit supports planar formats eg YV12, YUY2, RGB32 and RGB24, and in color for all
	except of course Y8.	

	The only really small problem I see is that there has been no attempt to cope with
	any special color palette for Y8, so you would get whatever luma value any
	particular color would have had (and they are not in ascending order of value).
	v1.05, added 16 greyscale level colors, index 16 to 31, 16 = black, 31 = white..

	Further on color, the colors took a fair bit of time to select, it aint easy finding
	ones that dont look rubbish under YV12. However, all colors chosen look pretty good
	with the exception of one, DDIGIT_ORANGERED which is a bit blurry BUT was chosen
	as a sort catastrophic error denoting color and so is not expected to be used
	frequently. The colors chosen, all came from the standard Color Presets AVSI file,
	Thought I should restrict myself to using standard color names rather than making
	my own up, eg, DDIGIT_FISHFINGER_ORANGE or DDIGIT_PUTRID_PUCE.

	Control codes within print strings.
		 '\n', Newline, positioning cursor 1 line down and at left edge of screen.
		 '\r', Newline Special, moves 1 line down and positions cursor at original on-entry X position.
		 '\b', Backspace, obvious, not sure how useful this will be.
		 '\f', Forward Space, again obvious, re-uses formfeed code for this. Again, maybe not so useful.
		 '\t', Tab, @ character positions, every 4 characters.(relative screen LHS).
		 '\a', Color selection control code. Followed by any one of '0123456789ABCDEFGHIJKLMNOPQRSTUV-!*'.
			0 -> V select the colors 0 -> 31. (lower case also allowed)
	       		'-' selects DDIGIT_DEFAULT.
	       		'!' selects DDIGIT_HILITE.
	       		'*' selects the on entry color.



To configure DDigit, Edit the lines contained at the beginning of the DDigit.H file:-

// ---------------------------------------------------------------------------------
//  !!! Below lines configure DDIGIT and remove code, Edit as required !!!
//
// NOTE, DDigitTest enables BOTH MONOLITHIC & DISCRETE colorspace code, you are UNLIKELY to want this.
// NOTE, Enabling any of below, without enabling the code it affects, will do nothing.
// ---------------------------------------------------------------------------------
// ---------------------------------------------------------------------------------
// !!! ONE (or rarely both) OF THE BELOW TWO SHOULD BE ENABLED !!!
//
// MONOLITHIC ColorSpace Independant code, Includes Horiz,Vert,pixel,char, 32 color print, ctrl codes.
#define DDIGIT_ENABLE_MONOLITHIC_CODE			// DDigitS()
// 
// DISCRETE ColorSpace code, eg DrawStringRGB24() @ pixel coords (optional, color, ctrl codes).
#define DDIGIT_ENABLE_DISCRETE_COLORSPACE_CODE		// Does not require additional DrawString stubs.
//
// ---------------------------------------------------------------------------------
// ----------------------------------------------------------------------------------
// MONOLITHIC ONLY config [Stubs Additional to DDigitS()]
#define DDIGIT_INCLUDE_DRAWSTRING_FUNCTIONS		// Stubs, Print Strings @ Pixel Coords
#define DDIGIT_INCLUDE_DRAWSTRING_VERTICAL		// Stubs, Print Vertical Strings @ Pixel Coords
#define DDIGIT_INCLUDE_DRAWSTR_VERTICAL			// Stubs, Print Vertical Strings @ Char Coords
//----
// BOTH Monolithic & DISCRETE color space config
#define DDIGIT_INCLUDE_DRAWSTR_FUNCTIONS		// Stubs, Print Strings @ Character Coords
// ColorSpaces to enable support for (Affects BOTH MONOLITHIC & DISCRETE COLOR SPACE CODE)
#define DDIGIT_ENABLE_SUPPORT_PLANAR			// Enable PLANAR eg YV12 Support
#define DDIGIT_ENABLE_SUPPORT_YUY2			// Enable YUY2 Support
#define DDIGIT_ENABLE_SUPPORT_RGB32			// Enable RGB32 Support
#define DDIGIT_ENABLE_SUPPORT_RGB24			// Enable RGB24 Support
// BOTH, Enable control code handling support in print strings, including color control.
#define DDIGIT_ENABLE_SUPPORT_CONTROL_CODES	// Formatting + 32 color ctrl.
// BOTH, Font, Enable full character set (incl 128 to 223), Comment out saves 4kb (ASCII 32-127 only)
#define	DDIGIT_ENABLE_EXTENDED_ASCII		// Disable this, omits half of the font.
//										
// --------------------------------------------------------------------------------
// --------------------------------------------------------------------------------
// --------------------------------------------------------------------------------
//
// ------------ Other possible configuration stuff
#define DDIGIT_TABCNT		4					// Tab step setting (4)
// Color index's used for defaults
#define DDIGIT_INDEX_TO_USE_AS_DEFAULT		DDIGIT_WHITE		// DDIGIT_WHITE
#define DDIGIT_INDEX_TO_USE_AS_HILITE		DDIGIT_ORANGE		// DDIGIT_ORANGE
// Extended Luma cmap default index's, used for Y8 AND YV411 only (if skipping YV411 chroma)
#define DDIGIT_Y_INDEX_TO_USE_AS_DEFAULT	DDIGIT_Y_D			// DDIGIT_Y_D
#define DDIGIT_Y_INDEX_TO_USE_AS_HILITE		DDIGIT_Y_F			// DDIGIT_Y_F

//----

#define	DDIGIT_SKIP_YV411_CHROMA			// If defined, then print Luma Only for YV411

//----

// Enable ONE of Following: 0=most transparent, 4 least transparent(OPAQUE BLACK).
//
#define DDIGIT_BACKGROUNDFADE 0				// Background fade multiplier = 7/8
//#define DDIGIT_BACKGROUNDFADE 1			// Background fade multiplier = 3/4
//#define DDIGIT_BACKGROUNDFADE 2			// Background fade multiplier = 5/8
//#define DDIGIT_BACKGROUNDFADE 3			// Background fade multiplier = 1/2
//#define DDIGIT_BACKGROUNDFADE 4			// Background OPAQUE BLACK
// 
// ---------------------------------------------------------------------------------


DDigit MONOLITHIC:- Enabled via, #define DDIGIT_ENABLE_MONOLITHIC_CODE

// Draw EXT ASCII string at [x,y] PIXEL or CHARACTER coords with color[32] selection
// of forground. pix==true = pixel coords: vert==true = Vertical (top down printing)
// ctrl = false, temporarily disables control code handling, just used in testing full
// character set printing in Demo.

extern void __stdcall DDigitS(const VideoInfo &vi,PVideoFrame &dst,int x,int y,int color, \
	const bool pix,const bool vert,const char *s,bool ctrl=true,int length=0);


DDigitS() is the lo level MONOLITHIC core of DDigit. It implements printing at pixel and character
coordinates, both horizontally and vertically in 16+16 different colors for strings. There
is no individual routine for printing lone characters, only strings are handled.

The above defines eg: DDIGIT_INCLUDE_DRAWSTRING_FUNCTIONS make available stub routines
which just make the calling of DDigitS() a little easier, in this case it makes available
3 overloaded routines for printing text at pixel positions, horizontally, ie:

DrawString(const VideoInfo &vi,PVideoFrame &dst,int x,int y,int color,const char *s);
DrawString(const VideoInfo &vi,PVideoFrame &dst,int x,int y,const char *s);
DrawString(const VideoInfo &vi,PVideoFrame &dst,int x,int y,bool hilite,const char *s);

where you can call the stub with no color argument (defaults to white), with a bool
to denote hilite ON/OFF status (hi-lite ON in Orange), or with an int to denote
a color index 0-31. The 1st stub above is implemented as so:-

	void __stdcall DrawString(const VideoInfo &vi,PVideoFrame &dst,int x,int y,int color,const char *s) {
		DDigitS(vi,dst, x, y, color ,true,false, s);	// color is an index
	}

so there is no iterative calling of DDigitS() to render strings, DDigitS, does it all and
the overhead of the DrawString() type stubs is so small as to make it unnecessary to
disable them, even if you dont use them, but the option is there.

Anyway, take a look at the DDigit.H header file for further info.

If you mistakenly call DDigitS() for a colorspace that has not being enabled, then
nothing will happen, ie it will not crash, it just will not do anything.

// ---------------------------------------------------------------------------------

DDigit DISCRETE:-  Enabled via, #define DDIGIT_ENABLE_DISCRETE_COLORSPACE_CODE

Enabling the DISCRETE colorspace code will generate code for the enabled colorspaces,
eg if you #define DDIGIT_ENABLE_SUPPORT_PLANAR then these functions will be added:-

	void DrawStringPlanar(PVideoFrame &dst, int x, int y, int color,const char *s,bool ctrl=true,int length=0);
	void DrawStringPlanar(PVideoFrame &dst, int x, int y, bool hilite,const char *s);
	void DrawStringPlanar(PVideoFrame &dst, int x, int y, const char *s);

if you also #define DDIGIT_INCLUDE_DRAWSTR_FUNCTIONS then these function stubs will be added for character coords.
	void DrawStrPlanar(PVideoFrame &dst, int x, int y, int color, const char *s);
	void DrawStrPlanar(PVideoFrame &dst, int x, int y, bool hilite, const char *s);
	void DrawStrPlanar(PVideoFrame &dst, int x, int y, const char *s);

NOTE, The MONOLITHIC code requires a VideoInfo reference in the args list, whereas the DISCRETE code does not.

// ---------------------------------------------------------------------------------

Also included, a 'throw away' plugin that just shows DDigit in action,
nothing special but it does the job.
If you do take a look at it, dont forget to remove it from your plugins directory
afterwards. Plugin name "DDigitTest.DLL", compiled for Avisynth 2.5.
Also "DDigitTest26.DLL" Supports 2.6 color spaces.

	Args:-
		DDigitTest()	// Defaults to -1, SHOW MONOLITHIC DEMO
		DDigitTest(-1)	// SHOW MONOLITHIC DEMO
		DDigitTest(-2)	// SHOW DISCRETE DEMO
		DDigitTest(-3)	// SHOW short DEMO for new Info.h
		DDigitTest(0)	// Speed Test, No Print
		DDigitTest(1)	// Speed Test, DDIGIT MONOLITHIC
		DDigitTest(2)	// Speed Test, DDIGIT DISCRETE
		DDigitTest(3)	// Speed Test, INFO.H

		Note, the above args have changed from previous versions of DDigittest.

	Use the included AVS files.
		DDigitDemo.AVS
		DDigitTimeTest.AVS

Anyways, hope you find a use for it.

StainlessS @ Doom9.
// ---------------------------------------------------------------------------------

The new Info.h also now implements bounds checking and can be obtained from the
below address if you would prefer to use that:-

	http://avisynth2.cvs.sourceforge.net/viewvc/avisynth2/avisynth/src/core/

Or,

 The Info.h of May 2013 is included with this package (together with a
companion header, InfoF.h, providing Info.h with layout format printing).

Not much different to v1.06, added x64 to dll's, and fixed a few x64 warnings.

see MediaFire in sig, Look for DDigitTest in DEVELOPER Folder.
Zip includes 3 dll's. full DDIGIT + DDigitTest source, + Info.h + InfoF.h + full VS2008 project files for easy build.

Demo's DDigit Monolithic and Descrete renderers, + simple demo for Info.H with InfoF.H companion header.




Full Character Set (Identical for Info.H)

[IanB]

For those who do not want the multimegabyte deluge of advertising just for a 75K zip.

[StainlessS]

Really not sure what I've done wrong again, BUT ...
feel like I have had my arse kicked ... Again.
(Feel like the text in sig, is very pertinent)
PS, Plugin dated 1 month in future, no excuse, never
quite sure what day/month/year it is.
(If it gives the impression that I'm thinking ahead, this is accidental)

[IanB]

@StainlessS,

Nothing wrong. The site linked insisted on getting in my face before letting me download, so as a community service I attached your useful contribution directly to the forum.

[StainlessS]

Thanx Mr B, Must be getting paranoid.

[StainlessS]

I was wondering how DDigit compared with Info.H (from v2.5.8 source) for
speed and so knocked up a little test.

	sprintf(buf,"0");
	DrawStr(vi,dst,0,0,buf);							// Ensure that caching plays no part
	sprintf(buf,"TEST 1234567890ABCDEFGHIJKLMNOPQRS");	// Prefill buffer
	if(arg) {
		if(arg==1) {
			for(y=0; y< 16;++y) { // INFO.H
				DrawStringYUY2(dst,0*DDIGIT_CHAR_WIDTH,y*DDIGIT_CHAR_HEIGHT,buf);
			}
		} else {
			for(y=0; y< 16;++y) { // DDIGIT
				DrawString(vi,dst,0*DDIGIT_CHAR_WIDTH,y*DDIGIT_CHAR_HEIGHT,buf);
			}
		}
	}

and the AVS

AviSource("D:\AVS\TEST.AVI").AssumeFPS(250.0).ConvertToYUY2()
return Test(2)		# 0 = no print, 1 = Info.h, 2 = DDigit

Here are results in seconds, to render clip in VDub:

	   
              NOPRINT   INFO.H	DDIGIT
YV12          51	 154      86	
YUY2          46	 116      56
RGB32         58	 144	  64

EDIT: !!! IGNORE THE ABOVE TIMINGS, TOTALLY MISLEADING !!!

Timing were not very accurate, just used system time/date and
any timing could have been 1 or 2 seconds out. Also did not disable
Anti virus nor HIPS during test, but should give reasonable idea.

The Info.h test called the particular color space code directly where
the DDigit call was colorspace independant, also had to fix bug in
Info.h RGB32 source as it produced an access violation, below line.

unsigned char *dp = &dst->GetWritePtr()[(x + tx) * 4 + (dst->GetHeight()-1 - (y + ty)) * pitch];

Had to add the -1 after GetHeight() as it was "out of bitmap". Fixed this some time ago, in
DDigit, forgot that it was still there.

I was pleasantly surprised, I would have been happy had it been of comparible speed,
but it does quite well.

[IanB]

@StainlessS,

Thanks for reporting the height off by 1 in the RGB code bug.

I had noticed you cleaned up the parsing algorithm in your version. For performance this is a very good example of the "Never look down" rule.

Here is the the original info.h code. It scans across the font element in vertical stripes. It stresses the L1 cache by hitting both the same font and video memory 20 times in the inner loop. Definitely lots of looking down here

PHP Code:

const int pitchY = dst->GetPitch(PLANAR_Y);
BYTE* const dstpY = dst->GetWritePtr(PLANAR_Y);
for (tx = 0; tx < 10; tx++)
{
  for (ty = 0; ty < 20; ty++)
  {
    dpY = &dstpY[(x + tx) + (y + ty) * pitchY];
    if (font[num][ty] & (1 << (15 - tx)))
    {
      *dpY = 230;
    } else
    {
      *dpY = (unsigned char) (((*dpY-16) * 7) >> 3) + 16;
    }
  }
} 


Here is StainlessS' implementation it scans down the font element in horizontal stripes. It accesses each font line only once and accesses the video memory strictly sequentially.

PHP Code:

unsigned char *dpY = &dst->GetWritePtr(PLANAR_Y)[y * pitch];
for (int tyy = 0; tyy < DDIGIT_CHAR_HEIGHT; dpY += pitch, tyy++) {
  if((y+tyy >= 0)&&(y+tyy < height)) {
    unsigned short fbm=DDigitFont[num][tyy];
    unsigned char* rp = &dpY[x];
    for (int tx = 0; tx < DDIGIT_CHAR_WIDTH; fbm<<=1U,++rp, ++tx) {
      if((x+tx >= 0) && (x+tx < rowsize)) {
        if (fbm & 0x8000U) { // Character Foreground SET Pixel ?
          *rp = c1;          // Set Luma Foreground Pixel
        } else {
          *rp=(unsigned char)(((*rp-16)*7)>>3)+16;// Background, Luma*=7/8
        }
      }
    }
  }    
} 


A remaining minor optimisation could be to move the 2 bound tests outside the loops and precalculate DDigitFontNum as &DDigitFont[Num][0].

Leaving this as the inner loops :-

PHP Code:

...
for (int tyy = tytop; tyy < tybot; dpY += pitch, tyy++) {
  unsigned short fbm=DDigitFontNum[tyy]<<txleft;
  unsigned char* rp = &dpY[x];
  for (int tx = txleft; tx < txright; fbm<<=1U,++rp, ++tx) {
    if (fbm & 0x8000U) { // Character Foreground SET Pixel ?
      *rp = c1;          // Set Luma Foreground Pixel
    } else {
      *rp=(unsigned char)(((*rp-16)*7)>>3)+16;// Background, Luma*=7/8
    }
  }
} 


[StainlessS]

Well, what can I say, The previously posted times are a little misleading,
I had done the tests with a DEBUG version of the DLL which affected timings greatly,
more so for INFO.H than for DDigit, perhaps because DDigit is less dependent upon cache.
Either Ram Cache is disabled during debug execution, or perhaps the system does some
kind of covert monitoring. I tried killing off Antivirus and HIPS, all non essential
services etc including the MS MDM.EXE and still it goes quite slowly.

OK, I know you all hate me, I did try putting my head in the gas oven
(had heard that it is a painless way to go), but just could not do it.
Every time I fell asleep I woke up screaming when I burnt my ear on
the roast potato tin, and my hair kept catching fire.
It aint that painless, I can tell you.

Here are the revised timings,

Visual Studio 6

        NOPRINT   INFO.H   DDigit
YV12    49.92     96.22    79.38
YUY2    48.83     63.22    58.53 (No ConvertToYUY2() as source was huffyuv)
RGB32   57.66     73.25    65.70
RGB24   57.66     72.69    65.41
Y8      63.38     76.98    68.11 (With ConvertToRGB32() to view)

Toolkit 2003

        NOPRINT   INFO.H   DDigit
YV12    49.81     87.88    77.02
YUY2    48.55     60.36    56.45
RGB32   57.05     71.86    62.89

Also have folder C:\Program Files\Microsoft Visual Studio 8, dont know
where this came from, have a number of SDK's installed, maybe one of those
installed it, or perhaps left over from VS 2005 Lite edition. Anyway, compiled
with that and:

        INFO.H   DDigit
YV12    92.31    78.23

Also compiled DEBUG,

        INFO.H   DDigit
YV12    452.61   95.00

Yes, that's NOT a typo, 452 seconds, about 7 frames per second.

Perhaps it linked with a not quite compatible library or something,
but DDigit worked reasonably well.

Have implemented changes suggested by IanB, dont really think it
can be optimised much more.

@ IanB,

Could you please remove or replace link to Doom9, update DDigit via link in
opening post.

Anyways find second release via first post, also DDigitTest.DLL has been
updated to include the timing test, Compiled with TK 2003.

EDIT: Also note, the speed test has been modified since previous timings,
now fills entire screen except bottom line, reserved for timing readout.

[StainlessS]

@ IanB,

When at last attachment has cleared, can you please delete
the wrongly dated first one (DDigit_25_dll_20101017.zip),
it contains a little bug in that the DDIGIT_CHARACTERS
define is 224 instead of (224-32) ie 192. Thankyou.

[frustum]

Stainless, kudos; this has come in quite handy. I had started doing this myself and had spent an hour on it, adding yuy2 and rgb support (and swapping the x/y sweep order), then finding out that rgb buffers are upside down. I accidentally find your lib when looking for some other info. Not only is is more general and foolproof than what I was doing, it took under five minutes to download the zip, copy the files, and slightly change my calling convention. It worked the first time!

[StainlessS]

@Frustum

Glad it worx for U, always nice to hear ones work is of some use.
If you ever try implementing a v2.6 plugin, let us know (either way)
whether it works ok for eg YV24 etc.

[IanB]

I removed the other DDigit_25_dll_20101017.zip download. Hopefully this is the right one this time.

Also, all this tuning prompted me to re-factor info.h with major surgery, it does loops in the most optimal order now and the YV12 routine is now planar generic and is renamed to DrawStringPlanar(...). Man was the original code slow!

[StainlessS]

Originally Posted by IanB

I removed the other DDigit_25_dll_20101017.zip download.

Thankyou.

I would be quite interested in seeing the source for new
Info.h, have you a link please.

EDIT: I did at one point try to call colourspace dependent
fn's from within DDigitS() to do the rendering loops, providing
the pre-calculated args as a structure so as not to have
lots of stack args, but this turned out no faster than the
current DDigitS() method. Idea being that the smaller
and lighter colourspace dependent fn's would provide
better compiler register optimizations. As you seem to have
kept Info.h colourspace dependent, I would expect a little
bit better speed from yours, as the complex/heavy code
in DDigitS() would likely make register optimizations difficult for
the compiler.

[IanB]

As always in the CVS repository, avisynth > src > core > info.h.

No way X86 has enough registers to do all 3 loops plus the decisioning, but it doesn't really matter that much, this is C++, not hand optimised assembler. As I have restructured the code, the inner loop executes 10 times, bit shifting the font mask in a single int and sequentially accessing the pixel line data. The middle loop executes strlen(text) times, it picks up the next font mask and has the inner loop continue sequentially accessing the pixel line data. This maximises L1 cache performance for video pixels. The outer loop executes 20 times and has the middle loop re-access the text string data each time, but this is 1 access per 10 pixel accesses, the L2 cache can easily manage this. The pixels data access commence on the next line. But all this is pretty theoretical, practically all the improvement happened just by reversing the row/column order, moving the text scan into the middle loop gained a very minor amount.

Also the level at which these functions are targeted does not necessarily have access to a VideoInfo structure, to be able to select the appropriate routine would need this information and possibly limit the applicability of the code. When coding Avisynth functions best practice is to make pixel type and other VideoInfo decisions in the class constructor and then have the GetFrame routine blindly crank the handle.

[StainlessS]

Originally Posted by IanB

As always in the CVS repository, avisynth > src > core > info.h.

Arh well, got to figure out how that CVS stuff works, I got my
copy of v2.58 out of some zip, somewhere. Thanx for the link,
dont need to ask again.

Will come back when less well served with ale.

However, I do think I should point out something, I dont know
whether you rejected or did not spot the significance,
but the code marked in DDigitS() as EXT ASCII bug fix
might demand a little more consideration.

The code in the new Info.h does not strictly detect and avoid
problematic cases where out of font access is concerned.
As far as I know there is no Avisynth mandate that 'char' should
be either signed or unsigned, but in either case, the new Info.h
code dont perform to exacting standards.

Valid characters are from 32 (SPACE) to 223 (ydieresis) with
font index's of 0 to 191.

EDIT:-
Current Info.h

		int num = s[si] - ' ';
		if (num < 0) num = 0;

The DDigitS() code, (replacing CONSTANTS) :-

int num = s[si]; // or *s;
num = (num - ' ') & 0xFF; // Conv font ix, Ensure +ve char (Fix EXT ASCII bug)
if(num >= 192)
   num = 0;                   // Not in font, convert to SPACE

The subtraction and AND, result in an unsigned 8 bits of int
whether signed or unsigned char was concerned
(with or without the Visual Studio /J switch)
The comparison with 192, detects both characters that were less
than 32 (SPACE) or greater 223 (ydieresis) as all of the
invalid characters less than 32 will wrap around
to the font index interval 224 to 255. The invalid characters
224 to 255 will be in the font index range 192 to 223.

Also, the above snippet will correct any sign extension probs
propagated from, eg clients of the old DrawDigitYUY2 that
might use eg " *s - 32 " whether char is signed or not.

Info.h, as it stands, when signed char is used EXT ASCII
characters 128 & above [eg (c)opyright, chr$(137), I think]
will not print (never did under old Info.h) and if unsigned
then characters 224 and above will reach out of font with
rubbish results and potential access violation.


Still gotta digest the new Info.h, well impressed.

Gotta go chuck another can of Swan on the barbie.

Thanx for being Mr B,

[StainlessS]

Have knocked up a new version of DDigitTest which does a simpler
series of tests for the new Info.h, showing the full character set,
chars 0 through 31 (invalid), 32 though 191 and 192 through 255
(invalid).

Also timing test included for new Info.h.

Here's some test timings:

            NOPRINT     NEW_INFO.H         DDIGIT
YV12       65.92          73.83             103.72
YUY2       23.63          26.66             28.06
RGB32      21.89          28.86             28.42
Y8         35.28          37.19             37.77

WOW!, Mr B, looks like I could do better with YV12.

Included in this temporary pack are three dll versions,
orig new info.h both with and withough /J switch,
ie unsigned and signed char versions, both showing
font range errors. And, a modified version new info.h
with the EXT ASCII fix applied showing proper output.

Got to dash before the bank shuts.

Here's a temporary link to this release, It will at some
time be deleted.

EDIT: Link DELETED

EDIT: The EXT ASCII bug fix is switched via "#define FIX_EXTASCII"
near the beginning of "Info_NEW.h".

[StainlessS]

New Version DDigit v1.01 see first post.

	v1.01, Mar 6 2011, Added control code parsing within print strings.
		 '\n', Newline, positioning cursor 1 line down and at left edge of screen.
		 '\r', Newline Special, moves 1 line down and positions cursor at original X position.
		 '\b', Backspace, obvious, not sure how useful this will be.
		 '\f', Forward Space, again obvious, re-uses formfeed code for this. Again, maybe not so useful.
		 '\t', Tab, @ character positions, every 4 characters.(relative screen LHS).
		 '\a', Color selection control code. Followed by any one of '0123456789ABCDEF-!*'.
			0 -> F select the colors 0 -> 15.
	       		'-' selects DDIGIT_DEFAULT.
	       		'!' selects DDIGIT_HILITE.
	       		'*' selects the on entry color.

YV12 speeded up somewhat.

Revised timing using DDigit v1.01 and Timings for new Info.h
of Oct 2010.

        NOPRINT           INFO.H(new)            DDIGIT          (1st figure average of 3, 2nd best time of 3 runs)

YV12      68.48            76.60                  77.74
          67.83            76.27                  77.38

YUY2      24.22            27.16                  28.71
          23.80            27.03                  28.50

RGB32     21.87            27.31                  28.89
          21.84            27.13                  28.22

RGB24     25.64            28.41                  29.95
          25.61            28.28                  29.83

Y8        35.04            38.88                  39.33
          34.50            38.75                  39.28

[StainlessS]

New Version DDigit v1.02 see first post.

Fix for planar dshift bug introduced in v1.01 6 Mar 2011.
Would not really affect YV12 (except perhaps printing last character in font,
ie ydieresis). Would though present problems in planar colorspaces where
there are vertically 4 luma samples to 1 chroma sample.
Hopefully, I got it right this time.
PS, planar speed test times may have gone up one or two tenths of a second.

[StainlessS]

New Version DDigit v1.03 see first post.

Adopted a 'new name' for the ColorSpace Independant Renderer in DDigit, new name being
"DDigit MONOLITHIC".
Added 'DDigit DISCRETE', NEW ColorSpace Dependant Renderers.
DDigit DISCRETE, has all the functionality of DDigit MONOLITHIC with the exception
of the vertical print functions.
Added DDigit DISCRETE to the DDigitTest() demo plugin.
Now using modified Info.h of April 2011.
Added unmodified Info.h together with an Info.h companion, InfoF.h which compliments
Info.h with formatted print via embedded control codes (see demo).

No timing test at present, really got to get some sleep before I fall down.

[StainlessS]

Timings for DDigitTest v1.03, 2nd June 2011

Compiled with Toolkit 2003, Optimizing Compiler.

                     DDigit       DDigit   April 2010
         NOPRINT   MONOLITHIC    DISCRETE    INFO_H

RGB24     23.70      27.62        28.03      26.02
          23.66      27.19        27.33      25.98

RGB32     20.09      26.68        26.88      25.46
          19.98      26.66        26.86      25.45

YUY2      22.77      24.14        24.05      24.17
          22.75      24.11        24.05      24.17

YV12      55.50      65.45        65.09      64.64
          55.45      65.38        65.06      64.59

Y8        31.86      35.90        35.40      35.90
          31.38      35.80        35.34      35.86

Compiled with MS VS6

                     DDigit       DDigit   April 2010
         NOPRINT   MONOLITHIC    DISCRETE    INFO_H

RGB24     23.70       28.67        27.90      27.65
          23.66       28.66        27.02      27.52

RGB32     20.10       27.78        26.97      27.08
          20.05       27.75        26.95      27.00

YUY2      22.85       25.12        25.55      23.88
          22.80       25.08        25.53      23.56

YV12      55.38       67.52        65.58      65.92 
          55.36       66.92        65.58      65.89

Y8        31.27       37.36        35.46      35.97
          31.25       37.31        35.41      35.92

1st Time = average of 3 runs, 2nd = fastest of 3 runs.

RGB32 was without ConvertToRGB32 (BlankClip default)

Y8 was with ConvertToRGB24 for viewing.

Timing can vary by as much as ~ 1.25 seconds.