I just want to check if there is any easy way to limit zooming. If I zoom beyond certain point, the axis look wired.
Is there any way to fix or limit the zooming?
Its with the JavaScript itself we cannot control it and it will be hard to get a reference to that axises even. It's logical to render the same value the limit.
Related
I've followed the answer in this post Cesium label blurred but have had no luck.
I've made sure that viewer.scene.fxaa = false and nothing seems to change. Please see my screenshot attached.
Does anyone have a fix for this?
Thanks so much!
Be wary of hard-coding something like viewer.resolutionScale = 2. There's a baked-in assumption on this line of code that the user probably has a high-DPI screen, and their browser is scaling up the webpage accordingly. Running this line of code on a system that is already using a 1:1 pixel ratio may cause it to render twice as wide and twice as tall as what the device can actually display.
Here's an alternate suggestion:
viewer.resolutionScale = window.devicePixelRatio
It's not perfect, but better than a hard-coded 2. It will attempt to get the Cesium viewer to exactly match the device's native pixels, which may not be the same size as "CSS pixels", particularly on high-DPI screens.
A value of "1" here (the default) means that Cesium's viewer canvas pixels are the same size as the webpage's idea of CSS pixels, which may be larger and chunkier than the screen's own native pixels. Higher numbers act as a multiplier on the WebGL canvas resolution, taking more graphics memory and performance. You may find that the machine you're testing this on already has a window.devicePixelRatio of 1.5 or 2.0, so the line above may not act any differently from a hard-coded 2 on your particular machine. But checking the local devicePixelRatio is better than making assumptions.
This can be fixed by adding:
viewer.resolutionScale = 2
May impact performance, but it seems fine so far.
I am thinking about converting a PDF document into a long scrolling HTML doc (my reason is that there is video in the document and we want to turn the video into streaming rather than require anyone viewing the presentation to download 200+mb before being able to view anything). I am wondering if there is a maximum pixel width or height to HTML documents, or if browsers start to have difficulty with the DOM at certain lengths. If I convert the whole presentation to HTML it would be about 41,000 px. Does that seem reasonable? Are there limits to the pixel height or width of documents? Or best practices considerations I should keep in mind?
On IE8 and lower CSS "filter" declarations fail on anything larger than 4096 pixels. This is not a restriction on document size but can sometimes cause unexpected results.
As far as I'm aware, browsers can render documents of literally any size. I had a world map page that was 40,000 x 20,000 pixels, and it ran perfectly fine, even with some fairly busy JavaScript.
It would be new to me that there is a limitation for maximum width or height of a webpage.
I have tried very big numbers and never got to a maximum.
I dont think there is any kind of limit, it will certanly be very slow to load 41.000px so my advice it´s not to do that...
I cant imagine someone scrolling down 41.000px, thats something almost crazy to do...
Find another way, split the video in small chapters.. chapter 1.. chapter 2..etc..
I'm working on a site that will be showing a lot of information via divs. Its basically a chart out of divs. The way its setup is I've got an outer div with a set size that you can scroll the contents around (click and drag like google maps).
From here I can 2 ways of going, have 1 large inner div that is moved around with all the chart divs within it. This would be by far the easiest approach. The other option I see is a tiled approach where I break the large inner div up into smaller divs and dynamically add/remove them as needed.
The chart itself is potentially 1999425014 pixels square. Each point is made up of 6 divs and there are 100,000+ points.
What would be the best way to move forward?
I believe most modern browsers render sections of pages only as needed. If the entire page fits in RAM, only the section that is currently visible is being drawn. I conclude this because large documents do not slow down my computer when I use other programs, but there is a bit of lag when I scroll across one. Plus, when the window is repainted through the operating system's APIs, only the pixels that are visible should be rendered. That would only make sense when designing it, anyway.
Surely you can fit as many as you want on a page without worrying about real-time performance hits, unless you're talking about scrolling. Rendering the document should take less time than retrieving it out of system memory and determining where the scroll bars are.
Best of luck, and merry Christmas.
-Tom
My question is not language based or OS based. I guess every system is offering some sort of TextOut(text, x, y) method. I am looking for some guidlines or articles how should I implement selection of outputed text. Could not find any info about this.
The only thing which comes to my mind is like this:
When user clicks some point on the text canvas I know the coordinates of this point. I need to calculate where exactly it will be in my text buffer. So I am traversing from the begining of the buffer and I am applying to each character (or block of text) a style (if it has any). After this, I know that after given style the letter has given size. I am adding its width and height to previously calculated X,Y coordinates. In this way, I am traversing the buffer until the calculated position has not reached the point that has been clicked by the user. After I reach the point within range of some offset I have starting point for the selection.
This is the basic idea. I don't know if this is good, I would like to know how this is done for real like for example in Firefox. I know I could browse the sources and if I won't have a choice I'll do it. But first I am trying to find some article about it...
Selecting text is inherently specific to the control which is containing it and the means it stores that text.
A very simple (though questionably inefficient means) is to run the text flow algorithm you are using when clicking on a point and stopping the algorithm when you have reached what is closest to that point. More advanced controls might cache the text layout to make selections or drawing their content more efficient. Depending on how much you value CPU time or memory there are ways to use caches and special cases to make this “hit test” cheaper.
If you can make any assertions (only one font in the control, so every line has the same height) then it is possible to make these tests cheaper by indexing the font layout by lines and then doing simple arithmetic to find out which line was clicked on. If your text control is also using monospace fonts (every character occupies the same width as well as height) then you are in even more luck, as you can jump straight to the character information via a lookup table and two simple divisions.
Keep in mind that writing a text control from scratch is obscenely difficult. For best practice, you should keep the content of the document separate from the display information. The reason for this is because the text itself will need to be edited quite often, so algorithms such as Ropes or Gap Buffers may be employed on the data side to provide faster insertion around the caret. Every time text is edited it must also be rendered, which involves taking that data and running it through some kind of formatting / flow algorithms to determine how it needs to be displayed to the user. Both of these sides require a lot of algorithms that may be annoying to get right.
Unfortunately using the native TextOut functions will not help you. You will need to use methods which give you the text extents for individual characters, and more advanced (multiline for example) controls often must do their own rendering of characters using this information. Functions like TextOut are not built to deal with blinking insertion carets for example, or performing incremental updates on text layouts. While some TextOut style functions may support word wrap and alignment for you, they also require re-rendering the entire string which becomes more undesirable in proportion to the amount of text you need to work with in your control.
You are thinking at a much lower level than necessary (not an insult. you are thinking that you need to do much more work then you need to). Most (if not all) languages with GUI support will also have some form of selectionRange that gives you either the string that was selected or the start and stop indices in the string.
With a modern language, you should never have to calculate pixels and character widths.
For text selection in Javascript, see this question: Understanding what goes on with textarea selection with JavaScript
Bit of a bizarre question, but does anyone know the actual limit to the length of a webpage, and why it is the limit?
As an experiment, I'm using HTML and CSS to make a site that represents a journey to a scale of 1:1. I have a ul list of markers along the way that I have separated with large margins in the css. However, the longest margin I can get to work so far is
top-margin:100000cm;
Since there are 43 list items, that equates to 4,300,000cm, or 43Km. Does anyone know why it's hitting a limit around this mark, or how I might go about getting it longer? I'm using Safari for testing currently.
There is no limit, as per any HTML/XHTML specification, so this is just the practical limit of the browser that you're hitting. How long a webpage can be is the same as asking how long a book can be.
It appears to simply be a maximum value that margin-top property can be set to. I've tried values up to 400,000cm with 100 elements and the page loads them all fine. I even tried incrementing that up to 1000 elements to see if the number was affected by load time, but nothing. It does appear to be an exact number somewhere between 400,000 and 500,000 that it cuts off at and shortens down past that value.
Code I used (which worked, showed in full):
<?php
print "<ul>";
for ($i = 1; $i <= 1000; $i++) print "<li style=\"margin-top: 400000cm;\">{$i}</li>";
print "</ul>";
die();
?>
Just a guess but 2147483647; max int value (probably pixels)
Interestingly though IE9 seems to go up to 214748.3px and when I go higher it goes into the negative.
18.939 kilometers, to be exact:
http://worlds-highest-website.com/
This will depend on the browser. There shouldn't be any clear limit on the length of the HTML file. The pure "length", as in pixels, shouldn't have any clearly defined limit either. Only, the more elements there are in the page, the more the browser has to do, and the sooner it may run out of memory. Memory is about the only limit there is.
There is no limitation. Even in terms of size of integer, you can create divs in other divs and have all of them biggest value of margin value so your page will not be limited.
It's a browser / memory / os architecture issue.
Measuring it in anything but pixels won't be very useful unless you are referring to the size of a printed webpage on a specific paper size, orientation and scale. Screens have different sizes and DPI's.
Besides a possible maximum int value, you need to consider the load time for the page. If your web page takes longer than a few seconds to show any interesting content, than you will lose people browsing your content. That's a more meaningful metric than a 1:1 scale metric.