2010-03-08 16 views
46

Czy ktoś może sugerować, kiedy używać SnapsToDevicePixels w WPF 4.0?Kiedy należy używać SnapsToDevicePixels w WPF 4.0?

Powinien być używany tylko okazjonalnie, jeśli występuje problem, w całej aplikacji, tylko w niektórych kontrolkach lub co?

+3

Lubię myśleć, że czyste, wyraziste linie sprawiają, że aplikacja jest profesjonalna i wypielęgnowana. Tak więc, moją radą jest używać go wszędzie tam, gdzie pomaga ten cel. – cplotts

Odpowiedz

73

Dobre odpowiedzi od Spencer i Martina na temat podczas w celu wyrównania pikseli.

Co do jak: Chciałbym również podkreślić, że należy w WPF 4.0 spróbować za pomocą właściwości UseLayoutRounding zamiast SnapsToDevicePixels.

UseLayoutRounding sprawia, że ​​to co robisz jest kompatybilny z Silverlight (SnapsToDevicePixels nie jest dostępny w Silverlight) ... a Microsoft jest również zachęcanie do korzystania z UseLayoutRounding nad SnapsToDevicePixels w swojej documentation.

Jaka jest różnica między tymi dwoma? Jedna duża różnica polega na tym, że UseLayoutRounding występuje podczas fazy układania, podczas gdy SnapsToDevicePixels występuje podczas fazy renderowania. To sprawia, że ​​spekuluję, że UseLayoutRounding jest prawdopodobnie bardziej wydajnym sposobem (nie potwierdziłem tego).

Wszystko to, co jest powiedziane, nadal będzie powód do korzystania z SnapsToDevicePixels. W rzeczywistości dokumentacja MSDN wskazuje na jedną. Dodam jeszcze jeden: tylko z SnapsToDevicePixels możesz użyć wskazówek do precyzyjnej kontroli.

Oto niektóre zasoby w tej sprawie (np.przyciąganie pikseli i jasności z obrazami, tekstem i grafiką):

Heh. Wiem, że moja odpowiedź była trochę większa niż to, o co prosiłeś ... ale ta koncepcja (tj. Niezależność od rozdzielczości i wynikające z tego problemy, które ona przynosi i jak sobie z nimi radzić) często może być punktem frustration podczas pracy z WPF. Przynajmniej chciałem wskazać ci nową właściwość WPF 4.0, UseLayoutRounding.

UPDATE

muszę tylko dodać od Widziałem to w kółko ... czasami SnapsToDevicePixels prace przy UseLayoutRounding nie. Chciałbym powiedzieć, dlaczego tak jest, ale zdecydowanie spróbuj najpierw UseLayoutRounding, a jeśli to nie zadziała, nie wahaj się wypróbować SnapsToDevicePixels.

Ta linia jest tak ostra, że ​​może cię przeciąć!

+0

Więcej = Lepsze w wielu przypadkach jest to świetna odpowiedź na wiele pytań, które miałem, szczególnie, że błagam, aby uzyskać wrażenie, że lepiej przenieść moją aplikację WPF/Linq do SQL na Silverlight/Linq do EF –

+0

Czy SnapsToDevicePixels = true może obniżyć wydajność WPF? –

+1

@Peretz prawdopodobnie nie zauważalnie ... ale włączenie go dodaje coś, co musi zostać zrobione/obliczone. Może efekt byłby zauważalny, gdybyś miał mnóstwo efektów wizualnych. Bardziej prawdopodobne jest jednak, że perfekcyjne trafienie zostanie utracone w ogólnie złym wykonaniu. – cplotts

5

Jednym z przypadków jest wyświetlanie obrazu lub wideo. Jeśli nie przyciągasz do pikseli urządzenia (np. Do pikseli ekranu wideo), to używasz jakiegoś algorytmu (interpolacja, wygładzanie), aby ustawić piksele obrazu "pomiędzy" pikselami ekranu, a to, co jest wyświetlane, nie będzie wyglądać tak dobre, jak oryginalny obraz. Obraz straciłby ostrość.

8

Powinien być używany w elementach sterujących lub obszarach, w których rozmieszczenie pikseli ma znaczenie. Kontrolki dotyczące płótna aplikacji do rysowania byłyby jednym przykładem. Czy widziałeś kiedyś mapę podzielonego dysku? To może być kolejny przykład.

Jeden wyjątek, jaki mogę wymyślić, to kiedy używasz linii podziału. Podczas gdy większość ludzi spodziewa się, że linie graniczne będą solidne, jeśli to ustawienie jest wyłączone, mogą wyglądać na niewyraźne i rozpraszające.

Zasadniczo, jeśli niewyraźne krawędzie są złe, wyłącz je.

+6

Prawdopodobnie masz na myśli * "jeśli krawędzie są rozmyte - włącz" * (ustaw "SnapsToDevicePixels = true", aby usunąć rozmycie). – Sinatr

1

Właśnie zauważyłem, że jest to bardzo przydatne dla granic. Informacje dodatkowe here.

<Style TargetType="Border" > 
     <Setter Property="SnapsToDevicePixels" Value="True" /> 
</Style> 
Powiązane problemy