I have a texture with 2048x2048 it simulates a computer monitor, its is to big because the size change with the monitor resolution.. So.. however when I render it with tessellator doesnt assumes the correct scale:

 

 

Renderized:

 

The code is:

 

@Override
public void drawScreen(int x, int y, float f) {
	//super.drawScreen(x, y, f);

	int xCenter = this.resolution.Width / 2; // Current Minecraft Width
	int yCenter = this.resolution.Height / 2; // Current Minecraft Height
	int midRectHeight = this.resolution.UsableHeight / 2; // This is the Current Minecraft Window Size minus the BorderSize
	int midRectWidth = this.resolution.UsableWidth / 2; // This is the Current Minecraft Window Size minus the BorderSize
	int topCenter = yCenter - midRectHeight; // Top X to Center the Rectangle
	int leftCenter = xCenter - midRectWidth; // Left Y to Center the Rectangle

	drawsScreen(topCenter, leftCenter);
}

private void drawsScreen(int x, int y) {
	// drawDefaultBackground();
	this.mc.renderEngine.bindTexture(new ResourceLocation("blazemachines",
			"/textures/gui/display.png"));

	double yFinal = y + this.resolution.UsableHeight; // This is the Current Minecraft Window Size minus the BorderSize
	double xFinal = x + this.resolution.UsableWidth; // This is the Current Minecraft Window Size minus the BorderSize
	yFinal = yFinal - ScreenResolution.BorderSize; // < BorderSize is 10
	xFinal = xFinal - ScreenResolution.BorderSize; // < BorderSize is 10

	Tessellator tessellator = Tessellator.instance;
	tessellator.startDrawing(GL11.GL_QUADS);
	tessellator.addVertexWithUV(x, yFinal, 0, 0.0, 1.0);
	tessellator.addVertexWithUV(xFinal, yFinal, 0, 1.0, 1.0);
	tessellator.addVertexWithUV(xFinal, y, 0, 1.0, 0.0);
	tessellator.addVertexWithUV(x, y, 0, 0.0, 0.0);
	tessellator.draw();
}

 

 

Sooo i make it! Solved :

 

GL11.glPushMatrix();
	GL11.glEnable(GL11.GL_BLEND);

	this.mc.renderEngine.bindTexture(new ResourceLocation("blazemachines",
			"/textures/gui/display.png"));

	ScaledResolution sr = new ScaledResolution(this.mc, this.mc.displayWidth, this.mc.displayHeight);

	GL11.glColor3d(190, 190, 190);
	this.drawTexturedModalRect(x, y, 0, 0, sr.getScaledWidth() - 10, sr.getScaledHeight() - 10);
	GL11.glDisable(GL11.GL_BLEND);
	GL11.glPopMatrix();

One performance improvement would be to cut the big image into smaller parts and just repeat/stretch those parts.

 

You could cut out one corner and a one pixel thin line of the frame. Out of those you could draw (stretch and rotate) the whole frame with a much smaller memory footprint for such a simple thing as a frame.

One performance improvement would be to cut the big image into smaller parts and just repeat/stretch those parts.

 

You could cut out one corner and a one pixel thin line of the frame. Out of those you could draw (stretch and rotate) the whole frame with a much smaller memory footprint for such a simple thing as a frame.

 

How much of a performance improvement would that be, and what kind of performance are we talking about? Is it better to have a bunch of textures stitched by the CPU/GPU into a big one than just have a big texture fetched from memory? Asking because I genuinely don't know. Seems like one way would be more CPU friendly and the other way would be more RAM friendly. Also the stitched texture method, while clever, isn't particularly texture-pack friendly, is it?

Well, in this case it might not be a too noticable change in performance, it all depends on the size of the texture(and compression level). As the size as mentioned is about 2k x 2k it's pretty big, and reducing the size to about 15x16 would save some memory.

 

And then there are more than one way of using those parts, either stich them together when loading(which kinda removes the benefit here) or just using a couple more drawcalls to draw each piece onto the screen at runtime.

 

And for texturepacks, the size for each piece doesn't have to be fixed, it can be flexible which means that texturepack creators have as much freedom as with one picture(though this might prolong the process of saving the image when you have to cut it apart)

 

This is mainly used for webpage design where each kB saved is better, in this case it really doesn't do much else than saving some MB of RAM(again, depending on original picture size) and squeeze a couple of drawcalls out of the GPU.

Thank you, that was informative.